Your Code Review Process Is Verbal. Here's What a Machine-Verifiable Proof of AI Code Safety Looks Like.

LineageLens has introduced a machine-verifiable AI code certificate system that issues signed attestations for AI-generated code, capturing model identity, risk score, and human review status at merge time. The system evaluates code against configurable policies and produces Ed25519-signed certificates that can be verified by third parties without workspace credentials, addressing gaps in traditional code review processes for compliance with regulations like the EU AI Act.

Most code review processes produce one artifact: a merged PR. Someone approved it. The review presumably happened. But if an auditor asks you to prove that the AI-generated function in your auth service passed your risk policy — that the model was on your allowlist, that the risk score was below threshold, that a human actually approved it — what do you hand them? A closed PR is not evidence of the above. It is evidence that someone clicked "Approve." The model identity, the risk state at merge time, whether the reviewer read the AI context or just the diff — none of that is in the PR. This is the gap that machine-verifiable AI code certificates close. When you merge AI-generated code today, you lose the generation context permanently. The commit records the diff. Git blame records the author. Nothing records which model generated it, what the prompt was, what the risk score was at insertion, or whether the human reviewer actually engaged with the full AI context. Post-merge, you're reconstructing from memory and process documentation. That reconstruction will not survive a security audit. It certainly won't survive an EU AI Act compliance review, where Article 12 requires records of AI system outputs to be kept for a period appropriate to the purpose. LineageLens's indemnity system issues certificates at three scopes: per-record, per-PR, and per-release. The evaluation runs against your workspace's active IndemnityPolicy . A policy has five configurable rules: class PolicyRules BaseModel : max risk score: int = Field default=70, ge=0, le=100 require license clean: bool = Field default=False require human review: bool = Field default=False allowed models: list str = Field default factory=list unknown review pass: bool = Field default=False cert ttl days: int = Field default=90, ge=1, le=3650 When you call POST /indemnity/certificate with scope=pr and scope ref=PR-442 , the service fetches every provenance record tagged pr:PR-442 , evaluates each one against all five rules, and either issues a certificate or returns a structured list of reasons why eligibility failed. The evaluation is explicit: Risk check if record.risk score is not None and record.risk score max risk: eligible = False reasons.append f"Record {uid}: risk score {record.risk score} exceeds policy maximum {max risk}." Model allowlist check if allowed models and record.model name: if record.model name not in allowed models: eligible = False reasons.append f"Record {uid}: model '{record.model name}' is not in the policy allowed-models list." Notice what this requires: the model name must be captured at generation time. The risk score must have been computed at insertion. Human review status must exist in ReviewQueue . If any of these are missing, the certificate either fails or the unknown review pass escape hatch applies — your choice, policy-level. When eligibility passes, the system builds a canonical attestation statement and signs it with Ed25519: php def sign attestation statement: dict - SignedAttestation: private key = load private key canonical = json.dumps statement, sort keys=True, default=str .encode sig bytes = private key.sign canonical return SignedAttestation statement=statement, signature=sig bytes.hex , public key id= get public key id private key , The sort keys=True ensures canonical key ordering regardless of Python dict insertion order — without this, semantically identical statements could produce different byte sequences and fail verification. The corresponding public key is available unauthenticated at GET /attestations/{public ref}/verify , so any third party can verify the certificate without workspace credentials. The attestation also includes prev hash — the record hash of the most recent hash-chained provenance record in the workspace. This anchors the certificate to the workspace's provenance history at the moment of issuance. You cannot retroactively alter the provenance records that supported it without breaking the chain. An ineligible evaluation is equally useful. The system issues an unsigned certificate with a structured reasons list: { "eligibility": "ineligible", "reasons": "Record abc-123: risk score 84 exceeds policy maximum 70.", "Record def-456: model 'gpt-4o-mini' is not in the policy allowed-models list.", "Record ghi-789: human-review status is 'pending' — policy requires 'approved'." } This is a machine-generated record of exactly which AI code insertions failed your policy and why — before the code shipped. None of this works without the provenance capture layer. If a record has model name = null because the insertion went through a path LineageLens couldn't proxy, the model allowlist check cannot run. If risk score is null, the risk check cannot run. The certificate is only as strong as the capture underneath it. This is the compounding argument for installing early: every day of uncaptured AI code is a day of records that cannot support a certificate. LineageLens is open source and free to install. The indemnity endpoint is part of the Plus/Max tier backend. The deeper cryptographic design walkthrough covers why Ed25519 over HMAC, the key derivation fallback, and where the policy gate should actually live. What does your team produce as evidence when AI-generated code goes to production? And would it survive a structured audit?