Attribute Capability Status

Scope

This reference separates repository implementation, immutable packaging, runtime inspection, product acceptance, and environment activation for the Attribute capability. It records the accepted AKS reference image without turning a successful request or runtime probe into a product status.

Definitions

Status	Meaning
SPECIFIED	Contract/design exists; runtime is not implied.
IMPLEMENTED	Repository code and tests exist; packaging or deployment is not implied.
PACKAGED	Artifacts are published or included in an immutable image.
DEPLOYED	An environment owner observed the exact artifact in an environment.
VERIFIED	The capability's complete acceptance contract has passed.
ACTIVE	The exact verified capability is enabled in its target environment.
BLOCKED	One or more required gates are incomplete or incompatible.
DISABLED	The system deliberately disables the capability.

Record ASSEMBLED as image evidence detail, not as a replacement for these lifecycle states. An assembled image can remain BLOCKED.

KEOPS #684 uses a separate runtimeState vocabulary. Its DEPLOYED value means that required components are available in the running realm. Product evidence uses productStatus; its DEPLOYED value requires an authorized environment owner to observe the exact artifact or image named by the record. Therefore runtimeState=DEPLOYED never implies productStatus=DEPLOYED, VERIFIED, or ACTIVE.

Allowed Values / Behavior

Capability ID	Current status	Evidence-backed statement	Open boundary
ATTR-DEFINITION-ADMIN	IMPLEMENTED	Definition CRUD includes versioned PATCH with ETag/If-Match; #871 owner filtering and #868 value/applicability concurrency are delivered.	Definition delete still lacks an owner-side expected-version contract.
ATTR-DIRECT-VALUES	IMPLEMENTED	Raw direct values, idempotent POST upsert, provider-side filtering/paging, and authoritative totals are delivered.	Direct values must not be presented as effective values.
ATTR-DEFAULTS-POLICIES	IMPLEMENTED	The bounded canonical read composes definition defaults and applicability inputs.	Inputs must not be presented as an effective winner.
ATTR-EFFECTIVE-VALUES	BLOCKED	The #867 diagnostic/provenance layer is delivered.	#80 effective resolution and #723 stable definitionId transport remain open.
ATTR-TOKEN-PROJECTION	BLOCKED (ASSEMBLED)	Exact AKS image runtime acceptance, historical manager-only Product Security acceptance, isolated-local T901 technical acceptance, and the released KEOPS #894 fail-closed consumer are available.	Image #392 remains blocked by Migration #287, Image #395, and GitOps #419. Candidate-qualified signed attestation, Console #4279 consumption, and Product Documentation completion also remain open. An authorized matching deployment observation is additionally required only for ACTIVE. CONFIDENTIAL projection and GİB are separate deferred lanes.

KEOPS #865 is complete for bounded provider-side value/fact queries and authoritative totals. KEOPS #866 is complete for the canonical Defaults and Policies input read. KEOPS #867 is complete for typed diagnostics and provenance. KEOPS #868 is complete for value/applicability optimistic concurrency, while definition delete remains a separate gap. KEOPS #871 is complete for authoritative definition owner filtering. These completed implementation records do not close #80 or #723 and do not promote the effective-value capability beyond BLOCKED.

The historical reference baseline remains Attribute Management v2026.8.30003 at 1ec709a6b7ae069426ce44986de9c3af3f918633 and KEOPS v2026.9.1003 at 11131dae3055477f73faba63d331b30fc6d2af7d. The first four current records instead resolve their stable evidence references to the released attribute-capability candidate backend rows below. Neither cohort is an accepted replacement image.

The attribute-capability candidate backend cohort is recorded as RELEASED in the machine-readable manifest: Attribute Management v2026.9.6, Membership v2026.9.3001, and KEOPS v2026.9.5 all have immutable registry evidence. This is a pending-integration cohort, not the accepted image. Migration integration, a new immutable image and exact acceptance must bind the whole tuple before the current capability matrix can consume it.

For every backend row, reviewedSourceSha identifies the reviewed implementation source and releaseCommitSha identifies the commit referenced by the immutable release tag. The release pipeline records its own source SHA and aggregate pipelineStatus; validationResult describes only the named validation job. Attribute v2026.9.6 and KEOPS v2026.9.5 have FAILED aggregate release pipelines with passed validation jobs. Their RELEASED state is supported separately by the existing release tag, registry package ID, and matching POM/JAR hashes; this documentation does not rewrite either aggregate pipeline as passed. Membership v2026.9.3001 has a passed aggregate release pipeline.

Every released cohort row has a globally unique, namespaced evidenceId. Capability evidenceRefs resolve those stable semantic identifiers rather than ambiguous child names such as attributeRuntime; a later immutable tuple substitution changes evidence bytes without changing the meaning of the reference.

The manifest's releaseFlowPolicy records the current delivery decision: preserve the existing release flow and defer the Pipeline/Image automation transition tracked by Pipeline #185, Pipeline #187, KEOPS #914, and Image #477. This scheduling decision does not provide technical acceptance, close those work items, bind the released backend tuple into an accepted image, or change any capability to VERIFIED or ACTIVE.

Promotion ownership and state boundary

Promotion is a separate, fail-closed chain; the accepted image record is not its authority:

• GitOps #429 owns the externally signed keops.attribute-projection-promotion/v1 attestation with VERIFIED and ACTIVE phases. A signed VERIFIED attestation is valid without a deployment observation. A signed ACTIVE attestation additionally requires an authorized observation of the matching image digest.
• KEOPS #894 owns the authenticated, fail-closed admin read model. It exposes UNAVAILABLE, VERIFIED, or ACTIVE; signed VERIFIED remains VERIFIED even when the independent #684 runtime read reports DEPLOYED. ACTIVE requires signed ACTIVE, its matching authorized deployment observation, and live #684 runtimeState=DEPLOYED.
• Console #4279 consumes the KEOPS read model. Only its exact ACTIVE result may enable the governed controls.

Image #392 remains the immutable ASSEMBLED evidence and operations-handoff owner. Image #392 does not sign or promote VERIFIED or ACTIVE, and Console does not reconstruct those states from Image, GitOps, or runtime evidence.

The current Image #392 closure DAG has three exact blockers:

• Migration #287 must supply migration operational acceptance.
• Image #395 owns the candidate-specific target-authority matrix; Image #400 is its evidence child and is not a separate authority decision.
• GitOps #419 must supply existing-realm reconciliation evidence.

Security #257 historical manager-only acceptance remains evidence for the recorded digest only. It does not replace the candidate-specific target authority owned by Image #395 and cannot clear any of these three current blockers.

GitOps #429's producer is delivered in merged !217. The pending signed-attestation gate describes actual candidate evidence, not the producer's implementation status. See the delivery and attestation distinction.

KEOPS #894's consumer is delivered in merged !566 and immutable v2026.9.5. Its current UNAVAILABLE result describes missing candidate-qualified signed evidence, not unfinished consumer code.

These future signed phases and API states do not rewrite the historical aggregate snapshot below. Its current productStatus remains BLOCKED, its promotion-owner gates remain PENDING, and its deployment observation remains NOT_OBSERVED until an authorized replacement record supplies the required evidence.

Used By

• Attribute Definition Model
• Attribute Values and Resolution
• Admin Console Attribute Workflows

Minimal Example

{
  "capabilityId": "ATTR-TOKEN-PROJECTION",
  "productStatus": "BLOCKED",
  "assemblyState": "ASSEMBLED",
  "runtimeAcceptance": "PASSED",
  "productSecurity": "HISTORICAL_MANAGER_ONLY_PHASE_APPROVED",
  "t901": "PASSED_ISOLATED_LOCAL",
  "migrationOperationalAcceptance": "PENDING",
  "targetAuthorityMatrix": "PENDING",
  "existingRealmReconciliation": "PENDING",
  "signedPromotionAttestation": "PENDING",
  "authenticatedPromotionReadModel": "UNAVAILABLE",
  "deploymentObservation": "NOT_OBSERVED"
}

Invalid Example

{
  "capabilityId": "ATTR-TOKEN-PROJECTION",
  "runtimeState": "DEPLOYED",
  "productStatus": "ACTIVE",
  "deploymentObservation": "NOT_OBSERVED"
}

The invalid example promotes state without the signed ACTIVE attestation, matching authorized same-digest deployment observation, live runtime requirement, and open product gates.

Immutable token-projection evidence

The exact AKS reference image is v2026.9.1001, source cd264a538f860da3d8eb0fdbb9e7e280bc9d1fc9, tree 2ae4acbc46b14018bd248bc0adb3cbce5fabade9, and digest sha256:fefde3b5ca01d0aaf0aedb1f85418cc3f2fab4b847e2dc6f62be2bd01205f93a.

• Assembly: pipeline 2810508684, manifest job 16239526920.
• Exact-image acceptance and lifecycle: pipeline 2810542712, jobs 16239794237 and 16239794238.
• Deploy-free operations handoff: pipeline 2810595081, job 16240208485.
• Product Security: Security #257, 9/9 scenarios passed for APPROVED_CURRENT_MANAGER_ONLY_PHASE; final evidence is note 3757319274. This is historical manager-only evidence for the recorded digest, not candidate-specific target authority. CONFIDENTIAL projection remains disabled and deferred to Security #290.
• T901: the realm-local technical matrix passed in an isolated local profile under GitOps #426, with bounded evidence in note 3757146654. It is not a shared-environment or same-image-digest deployment observation.
• Final evidence record: Image MR !176, reviewed head f6fa4328cfd2e7bede757e54da4b478277f7e767, merge commit ee06bfc88ccd29c31a5dd93e4b04d939b90e71d9, pipeline 2810709836.

The T901 #426 run used release 2026.8.29002, not candidate v2026.9.1001. Both identities are manifest-list digests; this is not a config-digest versus index-digest alias. The retained lifecycle job 16239794238 records them as distinct predecessor and candidate images (immutableDistinctImages=true). T901 #426 remains complete for its tested scope, but does not qualify the candidate for signed promotion. Security #257's historical manager-only acceptance likewise does not explicitly bind this candidate digest. GitOps #429 requires new candidate-qualified Security and T901 acceptance evidence before producing a real VERIFIED record. Synthetic publisher tests cannot replace it.

The acceptance run used the immutable image without rebuilding it, passed the governed 29-scenario five-surface matrix with zero failures/skips, preserved identical provider snapshots with zero injection, and passed the six-phase lifecycle test. It intentionally performed no release, deployment, promotion, Helm, ArgoCD or GitOps mutation.

Therefore this evidence proves ASSEMBLED runtime acceptance, not DEPLOYED, VERIFIED, or ACTIVE. The machine-readable source is evidence/attribute-capabilities.json.

Runtime Inspection Versus Product Evidence

Two released KEOPS reads help consumers inspect the running realm without promoting product state:

• KEOPS #683, released as v2026.8.23002 from 0126e4b35791a94538a87c1f80a6d14b641906b9, reads the bundles, rules, and native client assignments that currently reference one definition. It reports observable configuration, not ACTIVE or VERIFIED capability state.
• KEOPS #684, released as v2026.8.23001 from 041080302d474638d66b3eb99b1ca151a07622c0, reports runtimeState component availability as DEPLOYED, BLOCKED, or DISABLED. It cannot emit a productStatus, and its DEPLOYED result does not prove product deployment, VERIFIED, or ACTIVE; those states require the immutable evidence and product gates on this page.

A successful administration request is not a substitute for either read. GİB Nexus/profile acceptance remains a separately owned deferred release lane and does not block the accepted AKS evidence recorded here. A mutable next-build catalog that differs from the accepted tuple requires a new image and acceptance run; it does not retroactively invalidate this frozen reference image.

Notes

Repository release identity proves which source was published. Image acceptance proves the exact assembled cohort. VERIFIED does not require a deployment observation. Environment activation does: ACTIVE additionally requires signed promotion authority, an authorized observation of the matching image digest, and the live runtime result. Do not substitute one evidence layer for another.

For day-2 evaluation and the product-to-technical migration handoff, follow Attribute Capability Verification. For mismatched evidence, use Attribute Capability Status Troubleshooting.

Next Steps

Use Attribute Capability Verification to collect and compare the immutable source, image, deployment, and runtime evidence required by the next product-state decision.

Related Docs

Attribute Definition Model

Review definition identity and governance boundaries.

Attribute Values and Resolution

Distinguish direct, default, and effective values.

Identity Attributes and Claims

Follow the token projection decision chain.

Attribute Capability Verification

Apply the runtime and product state boundary operationally.

Capability Troubleshooting

Diagnose mixed or incomplete capability evidence.

Related Work

• KEOPS #80 — effective resolution
• KEOPS #871 — definition owner filtering
• KEOPS #723 — stable fact definition ID
• KEOPS #865 — value/fact query pushdown
• KEOPS #866 — Defaults and Policies read
• KEOPS #867 — effective diagnostics
• KEOPS #868 — remaining optimistic concurrency