Skip to main content

Attribute Administration

Goal​

Administer governed definitions and direct values without confusing stored data with defaults, policy inputs or effective results. Screen availability depends on the installed Admin Console and backend release; this guide describes the required product semantics, not an unverified screenshot.

Audience​

Use this guide if you design, implement, test, or operate the Admin Console Attribute area.

Prerequisites​

  • Understand stable definition identity and governance ownership.
  • Know which backend release and capability evidence are installed.
  • Have realm-management permission for the target realm.

Before You Start​

Do not infer capability activation from screen availability or a successful administration request. Check Attribute Capability Status and use the released runtime inspection endpoints when diagnosing the installed realm.

Worked Example​

The examples below administer a user attribute with semantic key language: inspect its definition, view a direct user value, review defaults and policies, and show an Effective Values result only when the server supplies a verified resolved response.

Steps​

1. Review Definitions​

A definition row must preserve stable definitionId separately from semantic definitionKey and show subject type separately from governance owner. Definition edits use the ETag returned by the read as If-Match. A 412 Precondition Failed means another writer changed the definition; refresh the record while preserving the administrator's unsaved input.

KEOPS #871 is complete: the released backend definition list applies governance-owner filtering, bounded paging, and authoritative totals. The browser must consume that result directly rather than reconstructing an authoritative inventory from a locally filtered page.

2. Review Direct Values​

Direct Values show stored records for the selected owner only. Creating a value is an idempotent upsert: the system creates a matching identity, changes it in place, or leaves it unchanged. The UI must not label this result inherited or effective.

KEOPS #865 is complete: the released backend applies provider-side value/fact filtering and bounded pagination and returns authoritative totals. Those totals still describe direct facts, not an effective inventory.

3. Review Defaults and Policies​

This view explains definition defaults and matching applicability records: stable definition ID, selector, required contexts, precedence, override/editability rules, merge behavior, provenance and versions. It does not compute the effective value in the browser. KEOPS #866 is complete and provides the released canonical bounded input read model. Console #4953 still owns the corresponding screen; backend delivery does not imply that the UI is available.

The console displays a definition with no matching binding as direct-only/no-inheritance.

4. Review Effective Values​

Effective Values represent a server-resolved, verified-context result. Each row needs typed status, stable definitionId, semantic key, redaction, ordered provenance, applied values/defaults/rules and versions, merge action, freshness and bounded conflicts.

The approved initial attribute rollout may let an administrator supply an exact membership identifier for this read only as SIMULATION or INSPECTION. That input must not create or replace Session Management selected-context state and must never be reused as token, policy, or runtime authorization authority. Positive runtime effective-role authority is deferred and unsupported in this rollout. Until the inspection server contract is released, the console must not synthesize this behavior.

The current /attributes/facts endpoint is direct single-owner behavior despite its historical effective naming. KEOPS #867 is complete and supplies the typed diagnostic/provenance layer, but the remaining inputs are KEOPS #80 for effective resolution and #723 for stable definitionId transport. Until both are complete, the console must not offer a misleading Effective Values view or calculate a winner locally.

5. Inspect Projection Configuration and Runtime​

The released per-definition projection read from KEOPS #683 returns observable bundles, rules, and native client assignments. The released runtime capability read from KEOPS #684 returns only DEPLOYED, BLOCKED, or DISABLED. Neither response proves VERIFIED or ACTIVE, and a successful definition or value request is not a substitute for these reads. Treat the endpoint value as runtimeState; runtimeState=DEPLOYED cannot promote product status.

The future promotion-state control must consume only the authenticated, fail-closed KEOPS read model owned by KEOPS #894. GitOps #429 owns the signed promotion attestation; Image #392 remains assembly/handoff evidence and is not the signer or promoter. Console #4279 owns consumption. The browser must not read Image or GitOps state directly, join evidence locally, or enable governed controls for UNAVAILABLE or VERIFIED; only an exact KEOPS ACTIVE result may enable them.

6. Review Sensitivity and Claim Controls​

The UI may expose evidenced sensitivity classification and authorized redaction state. It must not offer per-definition encryption, masking, retention, anonymization or legal-restriction controls as current behavior without a separately owned executable contract.

tokenVisible means eligible, not emitted. Show token release only when Security policy, confidential approval where required, native client scope/grant, mapper/orchestration, selected context and token surface all match. SENSITIVE never projects; absent or conflicting inputs omit by default.

Validation Scenario​

Scenario​

Inspect a direct language=de value when a separate default proposes language=tr.

Expected Result​

The Direct Values view shows only the stored de record. Defaults and Policies shows tr as an input. The console shows a winning value only when the effective endpoint returns a verified result with provenance; it never selects de or tr locally.

How to Verify​

  • Confirm definition and direct-value requests use the selected realm and owner.
  • Confirm the released #871/#865 server filters and authoritative totals are used without local reconstruction.
  • Confirm runtime status never promotes DEPLOYED to VERIFIED or ACTIVE.
  • Confirm no raw sensitive value appears in logs, errors, metrics, or evidence.

Troubleshooting​

  • A definition update returns 412 — reload the latest version and reapply the intended change; do not retry with a fabricated version.
  • A list total changes after local filtering — discard the local reconstruction and use the released provider-filtered total.
  • A direct value is absent from Effective Values — the effective contract is not delivered; do not reconstruct inheritance in the browser.
  • An eligible attribute is absent from a token — verify the complete Security rule, approval, client scope/grant, context, surface and mapper chain. Do not attempt to fix this by enabling tokenVisible.

Capability evidence​

The exact-image projection result is BLOCKED with ASSEMBLED evidence, never ACTIVE or product DEPLOYED. Product Security's recorded acceptance is historical and limited to its manager-only phase; CONFIDENTIAL projection remains disabled under Security #290. Security #257 is historical evidence for its recorded digest, not candidate-specific target authority. Image #392 remains blocked by Migration #287 operational acceptance, the Image #395 target-authority matrix, and GitOps #419 existing-realm reconciliation; #400 is evidence owned by #395 rather than an independent approval gate. Isolated-local T901 technical evidence is complete, but it is not a shared-environment or same-digest deployment observation. The KEOPS #894 fail-closed consumer is released, but its operational result remains UNAVAILABLE without an actual candidate-qualified attestation under the delivered GitOps #429 contract. Admin Console, Console #4279 consumption, and Product Documentation completion remain open. A matching authorized deployment observation is an additional requirement for ACTIVE, not for signed VERIFIED. GİB is a separate deferred release lane. The historical aggregate record remains BLOCKED with NOT_OBSERVED; the new promotion API states do not rewrite it.

Next Steps​

Review direct-versus-effective semantics before implementing a screen, then use the Attribute Capability Status page to verify which backend and runtime contracts are released.

Attribute Definition Model

Understand definition identity and ownership.

Attribute Values and Resolution

Distinguish direct, default, and effective views.

Attribute Capability Status

Review immutable evidence and open gates.

Attribute Capability Verification

Interpret runtime and product evidence safely.

Capability Troubleshooting

Diagnose evidence mismatches without client-side inference.