Architecture Note · Kling & Fisher

The AWS Reference Architecture

The Provenance position piece and technical companion make the case for the layer. This is what it looks like built: a three-account AWS reference architecture, developed with Ben Fisher, that separates execution, evidence, and audit into accounts with different humans administering each one.

A worked example

The reference architecture is specified against a concrete scenario: an agent selects an order amendment and obtains required human approval. Every box in the diagram below exists because that one scenario needs it, identity and policy at the top, the human decision in the middle, evidence capture running underneath it, and an independently administered account verifying none of it was altered after the fact.

AI Provenance on AWS reference architecture diagram, showing the customer application account, Provenance account, and independent audit account, with execution, evidence, and verification flows between them.

Blue arrows: execution and authority. Green arrows: evidence and storage. Purple dashed arrows: independent checkpoint verification.

Three accounts, three sets of hands

The architecture's central decision isn't a service choice, it's a trust boundary. Execution, the evidence ledger, and the audit function each sit in a separate AWS account, and the independent audit account is administered by different people than the other two. A system can't be asked to verify its own history credibly if the same operators control the system and the record of it.

Evidence can't be allowed to go missing in transit

Local database changes and outbox events share one transaction, so an action and the record that it happened are never allowed to diverge. From there, durable outboxes retain evidence until a receipt confirms the ledger accepted it, and delivery workers handle the SQS-plus-dead-letter-queue reconciliation that keeps pending evidence alive until acceptance, rather than dropping it on a transient failure. SQS is the initial transport; the delivery design is built to tolerate swapping in Kafka without changing the contract above it. The same verification rules that run in the application account also run in the independent audit tools, so an auditor isn't trusting the system's own account of whether its rules were followed.

The four pillars, mapped to this architecture

Each pillar from the Provenance specification lands on a distinct part of the diagram above, because no single AWS primitive covers identity, action, artifact, and decision at once.

Identity

The Identity Service and Policy service bind who or what acted, and under which human-controlled rule, at the moment the workflow starts, not inferred later from IAM logs.

Action

Workflow, Agent workers, and Action service capture what was done as a structural event in the Provenance SDK's capture path, not a line an application chose to log.

Artifact

The Artifact service creates and validates C2PA content bindings before anything lands in versioned S3 staging, so provenance travels with the artifact rather than beside it.

Decision

Human review, the durable hold, and the append-only ledger record why an action was authorized as part of the chain, reconstructable later with a defined scope and known gaps instead of assembled after the fact from tickets.

Status

In active development

This diagram reflects the proposed architecture. The implementation, and its Architecture Decision Records, currently live in a private repository co-owned with Ben Fisher. We're resolving how it's licensed before anything beyond this architecture overview publishes in full; our working default, consistent with how the rest of this work publishes, is open-source rather than closed. This page will link directly to the public repository and the full architecture document once that's settled.

← Back to Provenance