Canonical end-to-end flow: OACP authority overview.
Decision
The OACP helpers below lived in apps/auth-service/src/lib/commerce/oacp-trust-artifacts.ts
but no route, job or package ever called them. They are deleted, together with their tests.
Grantex no longer describes them as shipped.
What replaces them
- Artifact verification is the ES256 detached JWS verifier (
verifyOacpArtifact in
lib/commerce/oacp-jws.ts), described in OACP artifact authority.
It checks the signature against the published JWKS and the payload hash, then freshness,
scope, safety and the OACP Token Status List.
- Protocol mappings stay in the
protocol_adapter artifact’s adapter_mapping_profile,
which AgenticOrg renders from verified cached artifacts.
- Commitment, reconciliation and execution decisions are AgenticOrg’s deterministic arbiter
(a later phase of this programme), not a Grantex library.
Alternative considered
Mount the helpers behind the internal authority route
(POST /v1/commerce/oacp/c6z/authority-requests, same service-token auth) so AgenticOrg
could request adapter previews or eligibility packets from Grantex. Rejected for now:
- none of them took a signed artifact as input; they worked over unsigned fixtures, so
mounting them would publish output that looks authoritative without being verifiable;
- the UCP and ACP surfaces planned next are rewritten to the published specifications, and
the C6W4 shapes are not those shapes, so no later work needs them.
If a later surface needs an artifact-derived adapter from Grantex, it is built over
verified artifacts and mounted behind the authority route, with its own tests. Last modified on October 20, 2026
