Customer application API lifecycle

Verification Boundary

The local API dispatcher verifies run-signed context, evaluates authority, executes the customer application handler and reads real PostgreSQL fixtures. Assertions check permitted, forbidden, anonymous and other-customer callers and customer redaction; the file’s HQ write cases remain Operations evidence.

This register records static review at the supplied source commits. The suite exists, but this pass does not run it or mark its conformance verified.

What This Suite Proves

• The customer API separates three authority outcomes.
• Customer API facts omit staff and commercial detail.
• The same read key reaches only the caller’s customer.
• Customer application facts exclude staff commercial detail.

Bindings that span files are collective: each file contributes only its recorded assertions. The exact anchors are in frontmatter.

What It Does Not Prove

The register claims only the linked scenario outcomes at this boundary. It establishes no passing deployment result, complete permission matrix or unlisted cross-capability journey. Proposed scenarios and the remaining lifecycle, invariant and race obligations stay in the coverage findings.

Real Dependencies and Test Doubles

The dispatcher, route declarations, signed-context verification, authority evaluation, handlers, mappers, persistence, audit effects and PostgreSQL are real. The suite creates its signing key. Authorizer-flush jobs are written, but no Step Functions execution is started in this tier.

Must Not Be Doubled

Do not replace the dispatcher, route selection, signed-context verifier, evaluation, customer mapper, handlers, persistence or PostgreSQL with canned answers. The customer boundary and redaction assertions depend on exercising those real layers.