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.

The 2026-10-31 delivery checkpoint does not yet authorize the planned client-topology administration screens. Admin #4769/#4770/#4771 is tracked by Draft MR !1418 at exact source 768f54daa4e00179b55ff1f51fe9a13008154ff0; pipeline 3008952380 passed with warnings because its allowed-failure E2E job failed. It remains CODEOWNER-gated and unreleased. The source depends on the immutable backend contract that separates topology read permission from create/update/delete permission. The current temporary manage-realm gate must not be copied into frontend capability names or presented as the target least-privilege model. After that contract is released, the Admin source and its mandatory CODEOWNER, merge, release, deployment, and acceptance gates remain distinct.

The user Attributes screen structure is still a pending product decision. The proposed alternatives are Assigned values / Effective by context, one combined table, or separate Direct / Effective / Context views; no option is approved by this change. The invariants below apply to every option: editable direct values stay distinct from read-only server-resolved facts, independent working contexts are never unioned, and token projection remains a separate server-computed plane.

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 input is KEOPS #80 for effective resolution; #723 stable definitionId transport is terminal. Until #80 is complete, the console must not offer a misleading Effective Values view or calculate a winner locally.

Admin Console MR !966 is merged at source 5a6956531ab131588a24b4ea39f28956d01843e9 and merge commit 96322c8c3cc92f4b62855c17170746fcbd6004c0; exact pipeline 2850982459 passed. Its source integration is therefore terminal, but #4279 remains open because its description and checklist still require lifecycle reconciliation and final product acceptance. The merge is not an Admin Console release, final image, deployment, VERIFIED, or ACTIVE receipt.

The effective-by-context UI is merged from Admin #5214 / MR !1052 exact source e958254fe892dce0705c062bae84171e485ef717 as e7a51163bfec4e784a21f3cf15f5cb741bba9086. Exact pipeline 2875065102 passed. The merge remains unreleased and is not activation evidence. The screen uses the server-paged K3 contract and keeps ineligible membership contexts visible but non-inspectable; it does not reconstruct totals or effective values in the browser.

Separate Admin #4279/#5214 browser-acceptance MR !1069 is Ready and mergeable at exact source 4e0e8c249293b27d729f004ac3bddd03d3ef8fb3 / tree a180c04009927001fb5ba04e528fdd097e2e6ad8. Exact pipeline 2879482114 passed required validation (947 files / 9,426 tests), AI review and 42/42 authenticated E2E. Its isolated Chromium harness passed 2/2: changing membership replaces the query identity, resets the window and reaches page two; the release request includes the selected client UUID and excludes the unselected UUID. This validates the browser request boundary only. It does not execute Keycloak token issuance, establish an immutable image observation, or create VERIFIED/ACTIVE; CODEOWNER approval, merge and release remain open. The bounded #5214 checklist is 5/5 in In review, while #4279 stays 7/8 in Acceptance until the immutable-cohort selected-client claim is present, the unselected-client claim is absent, and the promotion truth remains honest.

Defaults and Policies acceptance is tracked by reopened Admin #4953 / Ready MR !1064 at exact source b838542d1f61e84910ed49ed3c45536e4e2ca7d7 / tree 412c2ccf339b967647c6a9f6a4065e7320147d6b. Exact-head pipeline 2879428625 passed required validation (950 files / 9,481 tests), production build, TypeScript, Sonar Quality Gate (86.4% scoped coverage), zero-finding AI review and 43/43 authenticated Chromium E2E in job 16714129415, including the Defaults and Policies scenario. GitNexus is exact/current at 49,795 nodes and 121,445 edges. The contract-bound and localization findings are addressed, all discussions are resolved and the MR is mergeable. EC01-06 are checked; EC07 exact-head human approval is still open, with CODEOWNER review re-requested from Eren Kan, Muhammed Oguz and Burak Yıldırım. Until approval, merge and release, this work remains non-terminal and must not be treated as the final Console gate.

Admin #5166 / MR !1009 is also terminal merged at source 00b015b9d5f0573782ea467e33520da58a297801 as acf43d608aa686de811d69dca907728bd68758f3; pipeline 2853683617 passed. It restores the otherwise-authorized write path when KEOPS reports advisory promotion evidence while retaining a clear warning. It does not turn UNAVAILABLE into ACTIVE, bypass authorization, or prove an Admin release.

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 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.

KEOPS #1071 / !662, first contained in v2026.9.20001, makes promotion enforcement opt-in. Default ADVISORY keeps a non-ACTIVE result visible as a warning and does not add a promotion-evidence block to an independently authorized non-promotion mutation; explicitly configured ENFORCED blocks every non-ACTIVE result. ADVISORY never authorizes a mutation or weakens its normal authorization checks. ACTIVE remains fail-closed in both modes and requires the authenticated and signed ACTIVE result, a matching authorized observation, and runtime DEPLOYED; neither a successful request nor the advisory UI may manufacture it.

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.

Render orgId and vdKodu only as ORGANIZATION_UNIT-owned contextual facts returned for the verified selected branch. Do not copy or relabel them as direct or inherited USER values. Direct selected-OU projection is released by #1043, and generic effective projection is released by K1/K2; final image, promotion and Admin release evidence remain separate gates.

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 server-side subjectType filtering is used only when the released provider contract is installed. Admin #5079 / MR !991, #5078 / MR !992, and #5082 / MR !994 are terminal merged source integrations with passed exact-head pipelines 2846013775, 2846070573, and 2844300684. Their retained local, browser, Sonar, AI, and independent-review evidence remains valid. The non-blocking recovery-pending follow-up is #5146. Merge does not constitute Admin Console release, deployment, VERIFIED, or ACTIVE evidence.
  • 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, Image #217 final exact-image acceptance, and GitOps #419 existing-realm reconciliation. Closed Image #395 and its supporting evidence are owned by #217; #395 is not an active blocker or an independent approval gate. Image #395 AC-09 is profile-scoped: an AKS result cannot approve the independently owned GİB #443 row, and neither row may be inferred from the other. 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.