Which records satisfy every AI coding tool's indemnity conditions at once: a unified evidence schema

Treat indemnity conditions as evidence requirements

AI coding assistant vendors attach conditions to their IP indemnity commitments. Typical examples include enabled filters, unmodified suggestions, required settings and customer-side practices. Interpreting those terms is a job for legal and procurement teams. The architect's job is narrower: make sure that for any piece of generated code, the enterprise can show which conditions applied and whether the system state at the time met them.

That framing matters because a policy statement is not evidence. NIST SP 800-218A defines an artifact as a piece of evidence, and evidence as data on which to base proof. A condition such as "the duplication filter was on" is only demonstrable if a retained record shows the filter state when the code was generated. NIST's generative AI profile also lists updating third-party contracts and service agreements, including GAI-specific indemnity clauses, as a risk-management action. Contract terms and technical records need to be read together.

The practical problem is scatter. Evidence sits in vendor consoles, IDE configurations, repositories and tickets, and it is rarely captured when the code is generated. Producing it for an audit, legal review or claim then becomes reconstruction work.

Evidence categories, sources and capture points

Indemnity conditions across tools tend to depend on overlapping categories, though each vendor will also have conditions of its own. Build a matrix of each tool's conditions against these categories, and mark each condition as common, vendor-specific, or not demonstrable by any record. Do not assume an overlap until it is checked against the vendor's terms.

The table shows where each category usually originates. Fields in the execution path can be captured at generation time. The others depend on external systems and should be flagged as such in the schema.

• Configuration state: Filter and setting status, versions. Source: vendor admin console, IDE or endpoint management. Often external to the execution path.
• Policy applied: Policy identifier and version at decision time. Source: enforcement point. Capturable at runtime.
• Code origin: Where suggested code derives from. Source: provenance analysis of the suggestion. Capturable at runtime where the path inspects it.
• Licence and security context: Licence findings and security signals on the code. Source: provenance analysis. Aligns with NIST's output-screening action for copyrights and other rights.
• Decision: Allow, redact or block per interaction. Source: enforcement point. Capturable at runtime.
• Attribution and downstream use: User, session, timestamp at runtime; commit, ticket and review links from repositories and ticketing. Partly external.

Retention, integrity and residency

Retention periods come from the governing instrument, not from the schema. A federal grant rule such as 2 CFR 200.334 sets a fixed period after a defined event, which shows the pattern, though it does not apply to coding assistant records. Set retention from the applicable contract, regulation and internal policy, and make sure the period outlasts the window in which a claim, audit or review could plausibly arise.

Three properties decide whether records are usable. Integrity: records should be tamper-evident and write-protected, with changes to settings and filters logged as events rather than overwritten. Completeness: gaps in capture should be detectable, so that a missing record is distinguishable from a nonexistent interaction. Residency: the evidence store should sit where your data location obligations require, and the prompt and suggestion metadata inside records may itself be sensitive.

Regulators can also require preservation of substantiating documents in specific matters, as an FTC order does for one respondent. That is not a general rule for AI coding records, but it is a reminder that the ability to produce supporting evidence is itself a requirement in some contexts. Liability apportionment among users, tool developers and dataset developers remains an open policy question, so avoid assuming responsibility sits with any one party.

Where runtime enforcement fits

Reconstruction after the fact depends on whatever each system happened to keep. Enforcement in the execution path produces the record as a by-product of the decision itself, so the evidence exists whether or not anyone anticipated a claim.

Trussed is one way to generate this class of evidence. It enforces policy in the execution path of coding assistants, with allow, redact, block, rate limit and escalation for human approval applied to individual interactions. It provides code provenance covering origin, licence and security context, and it produces audit-ready evidence from enforcement, mapped to frameworks including NIST. Deployment is self-managed in the customer cloud, with configurable retention and data residency. Fields that live outside the path, such as vendor console settings, repository history and tickets, remain external sources that the schema should reference.

None of this establishes indemnity coverage. It gives legal and procurement teams a consistent record set to test against each vendor's conditions.