Attribute Capability Status Troubleshooting

Symptom

An attribute administration request succeeds, the KEOPS runtime capability endpoint reports runtimeState=DEPLOYED, or an image test passes, but the product capability still reports productStatus=BLOCKED. A screen or integration may also show a state that does not match the immutable evidence record.

Likely Causes

The operator mistook runtime component availability for product deployment or activation.
A release, test pipeline, package identifier, artifact hash, source tree, or image digest belongs to another cohort.
Image #392 closure is still blocked by Migration #287 operational acceptance, Image #395 candidate-specific target authority, or GitOps #419 existing-realm reconciliation. Image #400 is evidence under #395, not a separate authority decision.
The candidate-qualified signed attestation, Console #4279 consumption, or Product Documentation gate remains incomplete. GitOps #429's producer and the KEOPS #894 consumer are delivered; neither supplies the candidate attestation itself, so the authenticated result remains UNAVAILABLE.
A signed ACTIVE claim lacks an authorized matching same-digest deployment observation or live #684 runtimeState=DEPLOYED. Deployment evidence is not required for signed VERIFIED.
The isolated-local T901 result was mistaken for a shared-environment or image deployment record.
The manager-only Product Security decision was mistaken for enabled CONFIDENTIAL projection.
A browser calculated inheritance, precedence, filtering totals, provenance, or conflicts from incomplete direct-value or policy-input data.

How to Diagnose

Check 1: Separate runtime state from product status

Read Attribute Capability Status. Confirm whether the value comes from the KEOPS runtimeState vocabulary or the immutable productStatus vocabulary. A runtime DEPLOYED result cannot promote product status.

Check 2: Compare one immutable evidence cohort

For each released backend row, compare the project, release, reviewed source commit, release-tag commit, release-pipeline source and aggregate status, validation-job result, test result, package ID, and POM/JAR SHA-256 values. The release-pipeline source must equal the release-tag commit. Do not promote a failed aggregate pipeline to passed because one job passed. For image evidence, compare the source tree and image digest as well. Stop if any identity is missing or belongs to another release.

Check 3: Inspect blockers without exposing values

Use bounded capability reason codes and the per-definition projection configuration read. Do not copy attribute values, tokens, credentials, user identifiers, or raw provider exceptions into a ticket or log.

Check 4: Verify the security and environment scope

Security #257 historical evidence records APPROVED_CURRENT_MANAGER_ONLY_PHASE for its tested digest. It is not candidate-specific authority and cannot replace the Image #395 target matrix. CONFIDENTIAL projection remains disabled under Security #290. The isolated-local T901 evidence proves its realm-local technical matrix only; it is not a shared-environment or same-digest image observation.

Check 5: Verify promotion ownership and phase

Read Image #392's closureDAG first. It must retain exactly the active Migration #287, Image #395, and GitOps #419 blockers; treat #400 as #395 evidence. Do not use the closed Security #257 historical decision to clear a current candidate gate.

GitOps #429 owns the signed keops.attribute-projection-promotion/v1 attestation. KEOPS #894 owns the authenticated fail-closed UNAVAILABLE|VERIFIED|ACTIVE read model, and Console #4279 consumes it. Image #392 supplies immutable assembly/handoff evidence; it is not a signer or promoter.

The completed producer delivery does not clear the candidate attestation gate. Check the matching signed evidence and read-model result, not whether the producer's issue is closed or its source pipeline passed.

Accept a signed VERIFIED phase without deployment evidence as a valid pre-deployment state. Accept ACTIVE only when the signed phase is ACTIVE, its authorized deployment observation matches the same digest, and the live #684 runtime state is DEPLOYED. Do not turn the historical aggregate BLOCKED/NOT_OBSERVED record into a current promotion state.

How to Resolve

Keep the narrowest evidence-backed productStatus; do not override BLOCKED in a browser or support workflow.
Select one immutable backend cohort and one immutable image record. Discard mixed-tuple evidence.
Complete each blocker at its owning repository: Migration #287 supplies operational acceptance, Image #395 owns the candidate target matrix, GitOps #419 owns existing-realm reconciliation, GitOps #429 produces signed promotion evidence, KEOPS #894 validates and exposes it, and Console #4279 consumes the KEOPS result. Do not manufacture a release coordinate, fill an unpublished row with branch data, or make the browser reconstruct state from Image/GitOps/runtime sources.
Use server-returned Direct Values, Defaults and Policies, and Effective Values as distinct views. Never calculate an effective winner or authoritative total in the browser.
Repeat product-state evaluation only after the immutable evidence record changes.

Signals to Inspect

Logs: bounded capability ID, component status, and reason code; no raw values or tokens.
Metrics: request outcome and latency without realm, user, client, or attribute-value dimensions.
Traces: the authorized read boundary and bounded provider status, with sensitive detail removed.
Audit events: who performed the administrative read and which immutable release/digest was evaluated, subject to the platform audit policy.

Escalation Notes

Escalate when evidence for the same capability mixes releases, a runtime response contains an unknown state, a UI promotes runtimeState=DEPLOYED, or a server response omits stable identity, version, provenance, or typed failure fields promised by its released contract.

Attach only the capability ID, bounded states/reasons, exact release or digest, relevant pipeline links, and reproduction steps. Route backend compatibility and migration details to Technical Docs #121.

danger

Do not expose credentials, tokens, raw attribute values, sensitive provenance, or unnecessary user identifiers while collecting evidence.

Attribute Capability Verification

Evaluate runtime and product states without inference.