Provenance as Infrastructure: An Architecture for Engineers Who Ship With AI

1. The Problem in Engineering Terms

Your engineers now use generative AI across the stack: code completion, whole-file generation, test synthesis, documentation, and increasingly design assets. Three engineering consequences follow that most orgs discover during an IPO diligence call or a platform store rejection:

• License contamination is now a supply-chain risk. Model output trained on permissively-licensed code can introduce copyleft fragments with no provenance trail. Once merged, the taint propagates through every downstream build — and most scanners only see the final tree, not when or how a license entered.
• Authorship is now an audit question. Under USCO guidance, your copyright position on AI-assisted code and creative output depends on documented human contribution. “Our engineers wrote it” is no longer a defensible evidentiary statement without the underlying record.
• Discovery is now routine. Counterparties in M&A, platform reviewers, and plaintiffs' bars all ask the same three questions: which models touched this artifact, what was the human input, and what license constraints apply. Teams that answer from memory lose credibility; teams that answer from a fixed record do not.

2. System Overview

The platform is three components with one invariant: evidence is generated as a byproduct of work you already do. No developer installs a new IDE plugin to remember to click “attest.”

2.1 The Capture Agent

• A lightweight daemon (Go, single static binary, ~8MB) that watches VCS events and creative tooling hooks on build agents and developer machines.
• Records origin events (first touch of an artifact), human edit diffs, and explicit approvals — hashed with SHA-256 and signed with your organization's attestation key via COSE.
• Batches and ships events over mTLS to the evidence store. Offline-tolerant: events queue locally and backfill on reconnect, so flaky dev networks never lose evidence.

2.2 The Evidence Store

• An append-only, merkle-chained log of all attestation events. Each record references its parents, making retroactive modification detectable by any verifier with the publication seal.
• Customer-held keys: attestation private keys are generated in your KMS (AWS KMS, GCP KMS, HashiCorp Vault, or HSM). AIthentica holds only public verification material — we cannot forge your evidence even if compromised.
• Region-pinned storage (US-East or EU-Central) with 11-nines durability and point-in-time export in open formats (JWS, COSE, JSON manifests).

2.3 The Scanner Engine

• Repository analysis that fingerprints code against a continuously updated license corpus: 40k+ OSS projects, full-text and structural matching (not just header scraping), with fuzzy detection for renamed or reformatted copyleft fragments.
• Dual-mode operation: delta mode scans only changed files per PR (seconds), full mode rebuilds the complete license map on demand (minutes for large monorepos, parallelized across shards).
• Findings carry entry-point provenance: which commit introduced a license exposure, whether it was AI-assisted (cross-referenced with capture events), and remediation status over time.

3. CI/CD Integration

The integration surface is deliberately small — one step in your pipeline, one webhook, one API:

• PR gate. A single pipeline step runs delta scan on changed files. Copyleft findings above your policy threshold fail the build with a machine-readable report (SARIF + JSON) and a per-file remediation diff. Typical overhead: 4–12 seconds for a standard service repo.
• Release seal. On tag or release, the pipeline requests a publication seal: merkle root over all capture events for that artifact set, signed and externally timestamped. The seal is attached to the release as an artifact — your distribution channels carry their own provenance.
• Policy as code. License policy lives in a versioned YAML file in your repo: allowed licenses, quarantine lists, per-directory overrides (e.g., vendored dependencies vs. first-party code). Policy changes go through normal PR review — no vendor console to keep in sync.
• API and webhooks. REST API for evidence queries and seal verification; webhook events on new findings, policy violations, and seal issuance so your compliance dashboard stays live without polling.

4. Security Model

• Zero source retention. The scanner processes fingerprints and license-relevant excerpts in ephemeral memory. Full file bodies never persist on our infrastructure — verified by our SOC 2 Type II audit scope.
• mTLS everywhere. Agent-to-store and API traffic is mutual TLS with short-lived certificates issued from your CA or ours, per deployment preference.
• SSO and RBAC. SAML/OIDC integration; role separation between evidence readers (legal), policy editors (security), and administrators. Every access to evidence records is itself logged in the audit chain.
• Self-hosted option. Enterprise deployments can run the capture agent and scanner engine inside your VPC with only seal verification phoned home — or fully offline, with seals verified against pinned public keys.

5. What This Buys Your Org

• Diligence readiness on demand. An IPO or M&A data room section generated in one click: complete license map with entry-point provenance, plus sealed authorship chains for flagged assets. Firms report diligence cycles shrinking from weeks to days when this exists.
• Platform store immunity. App store and model marketplace rejections over license questions become a copy-paste of the relevant evidence packet rather than a multi-week correspondence.
• Copyleft containment. Because findings carry entry commits, you can answer “how did GPL get into this service?” with a single SHA — and prove it was quarantined before release.
• AI governance without AI police. The capture layer records which artifacts involved generative tooling as a factual byproduct. Your AI usage policy becomes enforceable from data, not honor system.

6. Deployment Path

• Day 1. Connect a repository read-only. Full baseline scan runs; you get the license map and entry-point history with zero pipeline changes.
• Week 1. Enable delta gating in staging pipelines. Tune policy thresholds against the baseline so the gate fails on real regressions, not historical noise.
• Month 1. Production gates live, release seals enabled, capture agents deployed to build infrastructure. Legal receives the first sealed evidence packet for the current release train.