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.

No matching binding means direct-only/no-inheritance. A browser must not infer applicability, merge strategy or a winning default from incomplete records.

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, but it cannot produce a truthful effective result until #80 supplies resolution and KEOPS #723 preserves stable definitionId through the fact transport.

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 already owns stable definition identity, but the current KEOPS fact transport drops definitionId; KEOPS #723 tracks that additive correction.

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.