the-custodian/docs/assessments/2026-09-09-helixforge-approval-consumer.md

HelixForge approval consumer — 2026-09-09

The consumer implementation now removes manual approval-token renewal from the intended factory path. Secrets Engine exchanges its own client secret immediately before claim and consume, requests only the relevant scope, and holds the access token in memory. Live credential delivery remains separately gated.

The pinned KeyCape image exposed a consumer incompatibility missed by its old fixtures: assurance.aal/method was assumed; the issuer emits assurance.level/methods. The shared consumer now validates the actual shape. OpenBao and approval client identities retain their distinct audiences, tenants and scopes. Mixed providers, fallback identities and credential redirects are refused.

Validation: 350 tests passed. A repeatable disposable exercise also passed nine checks using the pinned KeyCape image and real Approval Engine source, JWT/JWKS verifier and SQLite store. It proved operator create/approve, consumer claim/check/consume, idempotent retry and the specified action/claim/secret/scope refusals. Temporary resources were removed; exact consumer module hashes are recorded in the evidence.

The PDP was a sequencing double. This proves the identity/consumer integration, not a production authorization path, native OpenBao delivery or factory throughput. No live credential was retrieved and no paid model ran.

Work coordination now reflects the actual scope:

• RPF-WP-0035-T05 is done against the completed verifier-only acceptance. RPF-WP-0035-T06 is its live client-side admission residual. The already completed CCR reviews must not recur as blockers.
• SECRETS-WP-0008-T02 is progress for the returned FLEX-DEC-2026-012 contract. The consumer must use submitted_request_digest for its exact request and compare the approval digest between evaluator outputs. This is actionable local implementation, with no outstanding interpretation question.
• SECRETS-WP-0009-T03 remains wait for that replay correction plus separate client-side admission, audit custody, live approval deployment and native credential authority/delivery. The identity exercise does not close these.

The next implementation is the submitted-request replay and approval-digest join, tested against independently published owner fixtures. Then complete the two consumer admissions and audit sender/receiver custody, deploy Approval Engine, and prove native delivery before admitting a bounded Railiance worker run.

The first internal capability remains reuse-surface; Railiance Fabric remains a candidate for broader reuse. vergabe-teilnahme remains the primary customer product repository. Progress toward that goal is reduced manual integration and fewer misleading waits; sustained factory throughput has not yet been measured.