Implement signed public and encrypted private provenance

[jmcte]

Problem statement

AI attestation is not the required signed public provenance plus encrypted private provenance system.

Desired outcome

End-to-end provenance generation, verification, redaction, encrypted logical-sink storage, audit evidence, and fail-closed material gates.

Scope

• Public schema/manifests under provenance/runs.
• Signing and verification.
• Secret filtering and typed placeholders.
• Encrypted bundle abstraction, S3-compatible adapter, OIDC, retention/Object Lock docs, audited reads.

Non-goals

• Physical bucket names or long-lived credentials in repositories.

Acceptance criteria

• All required public fields and reviewer lineage validate.
• Literal credential fixtures never enter public or private output.
• Logical sink works with short-lived identity and separate read/write roles.
• Required capture failure blocks material merges.

Test expectations

Begin with adversarial redaction, signing, tamper, encryption, retention, sink-failure, and audit tests.

Security implications

Create a threat model and require independent security review before remote sink use.

Documentation implications

Publish schemas, operations, recovery, retention, and audit guidance.

Dependencies

Flow provenance semantics, resolved contract, and conformance core.

Human decision points

Private-data exposure, retention exceptions, external obligations, and production sink spending above threshold.