Skip to main content

Attribute Capability Verification

Goal​

Determine the evidence-backed state of attribute administration, effective resolution, and token projection without promoting a successful request or runtime component probe into product activation.

Audience​

Use this guide when operating or supporting a Keymate realm that exposes attribute APIs.

Prerequisites​

  • Read Attribute Capability Status.
  • Identify the installed immutable release or image digest.
  • Use a principal with realm-management permission for read-only runtime inspection.

Before You Start​

Keep two state vocabularies separate:

  • runtimeState comes from the KEOPS runtime capability endpoint. Its DEPLOYED value means that the required components are available in the running realm.
  • productStatus comes from the immutable product evidence record. Its DEPLOYED value requires an authorized environment owner to observe the exact artifact or image identified by that record.

runtimeState=DEPLOYED never proves productStatus=DEPLOYED, VERIFIED, or ACTIVE. A successful definition, value, or projection-inspection request proves only that the specific request completed.

Worked Example​

Assume the runtime endpoint reports runtimeState=DEPLOYED, the immutable AKS reference image passed its exact-image tests, and the product record reports productStatus=BLOCKED with deploymentObservation=NOT_OBSERVED. The correct operator result remains BLOCKED. Do not replace it with DEPLOYED, VERIFIED, or ACTIVE.

Steps​

1. Read the product evidence record​

Start with the versioned record in evidence/attribute-capabilities.json. Confirm the capability ID, productStatus, blockers, release identities, test evidence, artifact hashes, and image digest. Reject a record with a missing or incomplete required field.

2. Inspect runtime state without promoting it​

Use the released read-only KEOPS capability endpoint for attribute token projection. Treat DEPLOYED, BLOCKED, and DISABLED as values of runtimeState only. The endpoint cannot return or prove the product states VERIFIED or ACTIVE.

3. Inspect projection configuration separately​

Use the per-definition projection read to inspect observable bundles, rules, token surfaces, and native client assignments. This read explains configuration that references one definition; it does not prove an effective value, successful token release, or product activation.

4. Compare immutable identities​

Require the reviewed source commit, release-tag commit, release-pipeline source and aggregate status, validation-job result, package identifiers, and POM/JAR hashes for a released backend cohort. The release-pipeline source must equal the release-tag commit. A passed validation job does not make a failed aggregate pipeline pass. For image evidence, require the exact source tree and image digest. Never combine evidence from different cohorts or substitute a mutable branch for an immutable release.

5. Record the narrowest supported result​

Keep the capability BLOCKED when any required product or environment gate is incomplete. The isolated-local T901 run under GitOps #426 passed its realm-local technical matrix, but it is not a shared-environment or same-image-digest deployment observation. Product Security #257 is historical manager-only acceptance for its recorded digest. It is not candidate-specific target authority. CONFIDENTIAL projection remains disabled and deferred to Security #290.

6. Keep release-flow scheduling separate from readiness​

Read releaseFlowPolicy as a delivery decision, not capability evidence. Its current value preserves the existing release flow and defers the Pipeline/Image automation transition. The deferred work items remain open, and the decision cannot fill an unpublished release tuple, satisfy an activation gate, or promote BLOCKED to VERIFIED or ACTIVE.

7. Follow the promotion-owner chain​

First read the closureDAG owned by Image #392. Its current closure requires Migration #287 operational acceptance, the Image #395 target-authority matrix (with #400 as evidence), and GitOps #419 existing-realm reconciliation. These are candidate closure gates; Security #257 historical acceptance cannot satisfy them.

Use GitOps #429 as the owner of the signed keops.attribute-projection-promotion/v1 attestation. Its signed VERIFIED phase does not require a deployment observation. Its signed ACTIVE phase does require an authorized matching deployment observation.

The producer implementation is complete: #429 is closed and GitOps !217 is merged at d5f237472dce53e5ad0a6cfea51bb18d3354b194. Its MR validation passed seven jobs, and the merged-source validation passed five validation jobs; the two optional release-branch jobs were not run. This is a source-only producer delivery, not a product image release or an operational signing run.

In the product evidence record, promotionOwnership.signedAttestation.state=PENDING and activationGates.signedPromotionAttestation=PENDING describe the missing candidate-qualified attestation, not unfinished #429 code. Keep both pending until the actual matching evidence exists. The delivered producer removed #894's implementation dependency. Merged KEOPS !566 and immutable v2026.9.5 now provide the fail-closed consumer, but without actual candidate-qualified signed evidence its operational result remains UNAVAILABLE and governed Console controls remain disabled.

Use the authenticated, fail-closed KEOPS read model owned by KEOPS #894 for the consumer state. It returns UNAVAILABLE, VERIFIED, or ACTIVE; only ACTIVE requires signed ACTIVE, the matching observation, and live #684 runtimeState=DEPLOYED. Console #4279 consumes that result and enables governed controls only for exact ACTIVE.

Image #392 remains the immutable assembly/handoff and closure-DAG record; it is not a signer or promoter. Keep the current historical aggregate record BLOCKED with deploymentObservation=NOT_OBSERVED while its #287/#395/#419 gates or the promotion-owner gates are pending. Do not infer its current status from the future API vocabulary.

Migration and Technical Ownership​

Product documentation owns operator-visible terminology, state interpretation, and safe migration expectations. The exact provider dependency order, API compatibility matrix, rollout/rollback procedure, and release-by-release technical migration evidence belong to Technical Docs #121.

During an upgrade:

  • keep existing direct reads under the Direct Values name;
  • do not label a default or applicability record as an Effective Value;
  • keep stable definitionId separate from semantic definitionKey;
  • preserve ETag/If-Match behavior on supported mutations; and
  • leave Defaults and Policies or Effective Values disabled until the installed immutable backend cohort and product evidence explicitly support them.

An administrative exact-membership input, if the released contract supports one, remains typed simulation/inspection evidence. It is not Session Management selected-context state and cannot be used to authorize a runtime policy or token.

This handoff does not prescribe an environment deployment. Follow the separately authorized release and operations procedure for the target environment.

Validation Scenario​

Candidate-specific acceptance boundary​

Do not reuse T901 #426 as acceptance of the v2026.9.1001 candidate: its isolated-local run used the distinct predecessor 2026.8.29002. Historical Security #257 acceptance also needs explicit qualification for the candidate digest. Keep both historical completions intact and obtain the candidate-specific evidence required by GitOps #429; do not infer applicability from a closed issue, a green image job, or synthetic publisher tests. See the immutable evidence and identity proof.

Scenario​

A support engineer receives a successful response from the runtime capability endpoint while the product manifest remains BLOCKED and has no deployment observation.

Expected Result​

The engineer records the runtime components as available and the product capability as BLOCKED. No screen, release note, or support response calls the capability VERIFIED or ACTIVE.

How to Verify​

  • Runtime evidence: the endpoint returns only the bounded runtime-state vocabulary.
  • Product evidence: the immutable record retains every incomplete blocker.
  • Release evidence: every released row separates reviewed source, release-tag commit, aggregate pipeline status, validation-job result, package, and artifact-hash data.
  • Audit evidence: the support record contains identifiers and reason codes, not attribute values, tokens, credentials, or user details.

Troubleshooting​

  • Runtime is DEPLOYED but product is BLOCKED — keep the product result BLOCKED; complete the named evidence gates instead of promoting the runtime result.
  • Release identities do not match — stop the comparison and select one immutable cohort.
  • The backend row is unpublished — keep all release, pipeline, package, and hash placeholders empty and keep the dependent capability blocked.
  • The automation transition is deferred — continue using the unchanged release flow, keep the deferred work items open, and make no readiness inference from the scheduling decision.
  • Promotion state is unavailable — #429's producer and the KEOPS #894 consumer are delivered, but an actual candidate-qualified attestation is absent, so the fail-closed result remains UNAVAILABLE and Console #4279 cannot enable governed controls. Do not read GitOps or image records directly in the browser, or mark product evidence ready because either implementation issue is closed.
  • Signed VERIFIED has no deployment observation — keep the consumer state VERIFIED; this is a valid pre-deployment state, not missing ACTIVE evidence.
  • A successful API request appears to prove activation — use the product evidence record; request success is not capability evidence.

Next Steps​

Use Attribute Capability Status for the current matrix or follow Attribute Capability Status Troubleshooting when runtime and product evidence disagree.

Attribute Capability Status

Review current product status and immutable evidence.

Attribute Values and Resolution

Separate direct, policy-input, and effective views.

Admin Console Attribute Workflows

Apply the evidence boundary to administration screens.

Capability Troubleshooting

Diagnose inconsistent or incomplete attribute evidence.