Skip to main content

Attribute Values and Resolution

Summary​

Keymate distinguishes stored Direct Values, Defaults and Policies used as resolution inputs, and server-resolved Effective Values. Keeping the views separate prevents a browser or integration from inventing inheritance, provenance, or a winning value.

Why It Exists​

Direct storage, defaults, applicability, precedence, and conflicts can influence one value. The model makes each input visible without treating an incomplete client-side calculation as truth.

Where It Fits in Keymate​

Attribute Management owns typed resolution. KEOPS supplies a verified realm-bound context and exposes the result; Admin Console renders the returned view without recalculating it.

Boundaries​

The current public facts operation is a direct single-owner read. Complete effective resolution, provenance diagnostics, and authoritative collection queries remain separately tracked capabilities.

How It Works​

Three Views, Three Meanings​

Direct Values​

A direct value is a stored row for one definitionId, owner scope/reference, value and source. The current admin API exposes raw direct values. POST /attributes/values is an idempotent upsert: the same backend identity is created when absent, updated in place when its value changes, and left unchanged when the value is identical.

Direct reads do not walk a tenant, organization, unit, group or user path. The value response carries basic source metadata, but that is not a complete effective provenance path.

Defaults and Policies​

A definition may carry a default and applicability records may carry selector, required-context, precedence, override and editability inputs. The system currently reads these inputs through separate contracts. KEOPS #866 is complete: the released canonical bounded read model composes those inputs for the Defaults and Policies view. It remains input data and does not calculate an effective value.

The current compatibility inputs are not permission for a browser to invent inheritance. The Phase 2 split model separates definition applicability/requiredness from inheritance-source policy; applicability, editability and a required-context flag do not themselves grant inheritance. Without an explicit source policy, Phase 2 USER resolution is direct-only/no-inheritance.

Effective Values​

An effective value is the outcome of server-side resolution against a verified realm-bound context. The target response includes stable definition identity, a typed outcome, redaction, ordered provenance, applied value/default/rule identifiers and versions, merge actions, and bounded conflict candidates.

That target is not the current /attributes/facts behavior. The current operation resolves one explicit owner only; it does not construct a verified owner path or apply inheritance/override. KEOPS #80 tracks effective resolution. KEOPS #867 is complete: its typed diagnostic and provenance layer is delivered, and KEOPS #723 is terminal for stable definitionId transport. A truthful effective result remains blocked until #80 supplies server-side resolution.

Effective USER inheritance and contextual facts​

These are different projection shapes. A definition whose subject is USER may resolve a value owned by a verified tenant, organization, organization unit or other supported upper scope only when an explicit typed inheritance policy authorizes that source. The winning value retains its original owner and provenance; it is never copied into the user's direct-value store.

A definition that describes the selected context itself is resolved directly for that contextual subject. The 2026-09-13 product-owner decision classifies orgId and vdKodu as ORGANIZATION_UNIT-owned contextual facts, not inherited USER facts. Their parent organization and tenant are context evidence, not substitute value owners. Attribute Management #65 now records that owner contract in its v1.3 oracle. KEOPS #1043 / MR !641 delivered the direct selected-OU projection path in immutable v2026.9.14005; 12/12 primary Maven coordinates passed authenticated target-version-clean SHA-256 read-back. The release receipt recorded Acceptance; live read-back on 15 September shows #65 OPEN / In progress with 15/15 rows checked and request-level acceptance still pending. Checked rows alone do not close the request. This bounded Phase 1 support does not implement generic effective USER inheritance across the full owner chain. See Attribute Capability Status for the exact current evidence boundary.

Approved Phase 2 Scope And Authoring Boundary​

Context Consistency At Token-Issuance Commit​

The 15 September owner decision for KEOPS #1053 defines the ordering point as successful native Keycloak token-issuance transaction commit, not literal HTTP-byte delivery. A relevant membership or topology change that commits first must invalidate the candidate. If token issuance commits first, a later change is a subsequent operation and does not retroactively invalidate that token.

This is an approved target rule, not a delivered concurrency guarantee. The actual owner-compatible protocol must cover supported membership, selected lineage and native session/cache writers through the accepted commit. Matching digests or reading the same models twice is insufficient. Real native after-final-read race and rollback/no-bearer evidence remains required; unsupported profiles fail closed. This rule does not make API success, metadata inspection or a local test an ACTIVE capability.

The target effective USER chain is GLOBAL < TENANT_TYPE < TENANT < ORGANIZATION < ORGANIZATION_UNIT < USER, resolved for the single server-verified selected membership branch. An explicit upper-source policy must allow an override before a more specific value can win; unequal same-tier values fail closed. Defaults are fallback inputs, not stored GLOBAL facts. A bounded typed ALL + GLOBAL policy without an owner ID describes only the canonical source edge in that verified realm; it does not select every tenant, organization, user or realm. New EXACT + GLOBAL, other unsupported ALL-source types and implicit legacy-row conversion remain disallowed.

First-release authoring keeps the existing native realm-admin boundary under KEOPS #1014 option C. No new tenant-admin, scoped-admin or user-self write permission is opened for definitions, applicability/requiredness, inheritance policy or direct values. UI visibility/editability is not authorization, and effective values remain read-only rather than copied into USER storage. The missing realm-admin policy API/composition is tracked by #1062; delegated tenant authoring remains later #1061. New split writes require the independently verified migration writer epoch/fence, not just a transaction or an ACTIVE reconciliation status.

Tenant #137, Organization #182 and Security #321 have independently qualified producer releases 2026.9.15. Their publication does not mean the full effective chain is integrated into token issuance or visible in the current Admin Console user Attributes tab. Attribute A1/A2, KEOPS K1/K2/K3, native acceptance and the final image/Console evidence remain separate gates.

Runtime projection checks value-free Security/client/surface/approval and native-scope eligibility before reading governed values; denied definition IDs must not enter value queries. Approved values then undergo value-dependent, conflict/cardinality and atomicity checks. Token visibility alone is not emission permission. The mapper only writes an immutable approved plan; login, refresh and hat switch revalidate the exact selected context and current policy instead of copying old claims.

Provenance and Conflict​

Current facts expose source type/reference plus optional freshness and confidence. Complete provenance must additionally identify which values, defaults and rules contributed, in what verified owner path and at which versions. A conflict is a typed outcome; it is not permission for a UI or client to select an arbitrary candidate.

The provider and the delivered #723 transport own stable definition identity. That delivery does not calculate inheritance or select an effective winner; #80 remains the resolution boundary.

Attribute #180's bounded VALUE_AND_RECORD_KEYS and Definition-page implementation is released in v2026.9.12 and adopted by Migration MR !254. Product deferred AC01 in the current phase rather than approving the candidate 6,000 ms request budget and 3,769 ms database-query ceiling. Parent #180 therefore remains open at 11/12 with native status Blocked; the approved values remain blank. The existing implementation, release, adoption, and measurement evidence stays valid and does not need to be rerun unless its inputs change or product reopens AC01. A UI or token consumer must not generalize that partial result into a complete effective-value capability.

Filtering and Totals​

KEOPS #865 is complete: value and fact endpoints apply provider-side filtering and bounded pagination and return authoritative totals. These direct/fact totals still do not describe an effective inventory; only the server-side resolution contract owned by #80 may do that.

Diagram​

Example Scenario​

Scenario​

An administrator compares a tenant default with a user's direct value.

Input​

Suppose a tenant default says language=tr and a user has direct language=de:

  • Direct Values can truthfully show the stored user value de.
  • Defaults and Policies can show tr and the rules that may apply.
  • Only a verified Effective Values result may declare which value wins and why.

Until the effective contract is delivered, documentation and UI must not label the direct fact as an inherited/effective result or promise automatic fallback after deletion.

Expected Outcome​

The UI presents both inputs in their correct views and waits for a verified server-resolved result before declaring which value applies.

Common Misunderstandings​

  • "A default is an effective value." A default is an input; only server resolution can select it.
  • "No direct value means the browser may choose an inherited value." Missing direct data does not authorize client-side inheritance.

Design Notes / Best Practices​

  • Preserve stable definition identity and source provenance across every resolution input.
  • Let the server resolve precedence and conflicts from a verified context.
  • Keep incomplete or conflicting resolution results fail closed and visible to operators.
  • Inspect a user's direct value without inferring inheritance.
  • Compare defaults and applicability rules before effective resolution is available.
  • Explain which inputs and versions produced a verified effective result.

Attribute Definition Model

Review identity, ownership, and applicability.

Admin Console Attribute Workflows

Apply the three-view model in administration screens.

Attribute Capability Status

Check implemented and blocked boundaries.