The day the model stops suggesting and starts writing
Up to a point, an AI feature is safe by construction. It reads. It searches, ranks, summarizes, drafts. When it is wrong a person notices, moves on, and nothing durable changed. Then someone asks the obvious question — why is a human retyping this into the case system? — and the feature acquires a write path into the thing the organization treats as authoritative. Every property that made the read-only version easy to ship is gone in that step. A wrong answer is no longer a bad suggestion. It is a row other systems reconcile against, that a decision cites, and that somebody eventually has to explain.
Teams reach this transition more often from the commercial side than the federal one. The product works, the model is good, and a customer — government or regulated commercial — says the output has to land inside their system. The questions that come back are not about accuracy. They are about what happens when the job runs twice, who approved the value, how you back it out, and where the evidence lives. Those are integration questions, and the model barely moves any of them.
A system of record is defined by what it promises, not by what it stores
Operationally the phrase means one thing: this is the copy every other system reconciles to, and its value comes from a promise — that at any point you can say what it said, who put it there, and on what basis. A system holding the same bytes without answering those three questions is a cache with good intentions.
The strictest regimes are worth reading even where they do not govern you; they are the shape of the questions that arrive. 44 U.S.C. § 3301 defines what counts as a federal record. 36 CFR 1236.10 requires records management controls for reliability, authenticity, integrity ("controls, such as audit trails, to ensure records are complete and unaltered") and usability — built into the electronic information system or into a recordkeeping system external to it. FDA's 21 CFR 11.10(e) is the sharpest sentence written on the subject: use secure, computer-generated, time-stamped audit trails that independently record the date and time of operator entries and actions creating, modifying, or deleting electronic records — and record changes shall not obscure previously recorded information.
Read that last clause as an architecture requirement rather than a compliance one and most of this article follows from it. An update that replaces a value has destroyed the record's ability to say what it said before — regulator or no regulator.
Retries are the normal case, not the exception
HTTP's definition is precise: a method is idempotent when the intended effect of multiple identical requests is the same as for a single one, and PUT, DELETE and the safe methods qualify (RFC 9110, §9.2.2). POST does not — and an AI pipeline's write is almost always a POST, because it creates an assertion rather than replacing a known resource.
Duplicate delivery is not a rare failure path; durable messaging is built on the assumption. AWS documents that Amazon SQS standard queues provide at-least-once delivery, that more than one copy of a message may be delivered because copies are stored across multiple servers, and that consumers must therefore be designed to be idempotent. Add a client timeout firing mid-commit, an orchestrator retrying a failed step, and an operator re-running a batch after an outage, and the single clean delivery is the special case.
The mechanism is a client-supplied idempotency key, and its status is worth stating precisely: there is no RFC for it. The IETF HTTPAPI working group carried a Standards Track draft for the header — The Idempotency-Key HTTP Header Field, draft-ietf-httpapi-idempotency-key-header — through seven revisions, and it expired in April 2026 without being published. Read it as a careful specification of an industry convention, not as a standard anyone can hold you to. The server stores the key alongside a fingerprint of the request and the outcome it produced. A replay with the same key returns the stored outcome instead of writing again. A replay with the same key but a different fingerprint is an error, not a second write, and that distinction is where implementations go wrong.
There is an AI-specific trap on top of the ordinary one. Derive the key from the triggering business event — this document, this case, this ingest run — never from the model's output. A key hashed from model output means two runs that phrase the same finding differently get two different keys, and the deduplication you thought you had writes the same fact twice. Non-determinism upstream must not become non-determinism at the write boundary.
The dual write is where audit trails quietly go missing
The write is rarely one write. There is the business row, and the event or audit entry saying how it got there. Committing to a database and publishing to a broker are two resources, and a failure between them leaves the pair inconsistent — silently: a value nothing accounts for, or an audit entry describing a change that never landed. The transactional outbox pattern is the standard answer, catalogued at microservices.io and documented as a cloud design pattern in AWS Prescriptive Guidance. Business state and outbound event commit in one local transaction — the event goes to an outbox table, not a broker — and a relay publishes it afterward, at least once. Consumers deduplicate on the event key: the previous section's discipline, one layer out.
The fields that have to be on the row
Provenance is not a log file. It is columns, on the same row as the value, written in the same transaction. The vocabulary is settled if you want it: the W3C's PROV-O, a Recommendation since 30 April 2013, models provenance as Entity, Activity and Agent with relations including wasGeneratedBy, wasAttributedTo and wasDerivedFrom. You need not serialize RDF — you need to answer the questions PROV asks.
| What the row carries | The question it answers | Who asks it |
|---|---|---|
| Source identifier and offsets | Where in which document did this value come from? | The reviewer re-deriving the value without your engine. |
| Producer identity — model name, version, weights digest, configuration hash | Which artifact, exactly, produced it? | Whoever has to scope a recall after a bad version ships. |
| Run identifier | Which execution, over which input snapshot? | Incident response: "which rows are affected?" |
| Asserted-by and confirmed-by, as separate columns | Who claimed it, and who accepted it? | Non-repudiation review (NIST SP 800-53 Rev. 5, AU-10). |
| State and supersedes-pointer | Is this the current assertion, and what did it replace? | Anyone reconstructing the record as of a past date. |
| Idempotency key | Is this a duplicate of a write already performed? | The retry, which will happen whether or not you planned for it. |
The control language follows once the columns exist. NIST SP 800-53 Rev. 5 AU-3 asks that audit records establish what type of event occurred, when and where, its source, its outcome, and the identity of individuals or entities associated with it. AU-10 asks for the capability to show that a given actor performed a given action. A row carrying a source identifier, a producer version, a timestamp and two distinct actor columns satisfies that almost mechanically. A model name and a prompt do not.
That gap is the most common miss. A prompt and a model version record how you asked; they do not let anyone reconstruct why the answer is what it is. Re-running a stored prompt is not verification — it repeats the process that produced the value and calls agreement proof. A reviewer needs a pointer into the source, checkable by string containment with no model in the loop, on the row rather than in observability storage with a thirty-day retention. More on tracing each statement back to the record it came from.
Confirmation is a state in the data, not a screen in the UI
A confirmation gate implemented in the front end is not a gate. It is a convention the batch job does not follow, the partner integration bypasses, the retry path skips, and some maintenance script steps around at 2 a.m. because it had to backfill 40,000 rows and the button did not scale.
Put the gate in the data model. Assertions land in a proposed state. The authoritative read view — the one downstream systems and people query — returns only confirmed rows. Promotion is its own transition, with its own actor, timestamp and audit entry. The gate is then enforced by whatever enforces the rest of your data integrity, and "can this be bypassed?" has a mechanical answer instead of a policy one.
This is also where federal expectations land on a commercial product. OMB Memorandum M-25-21, issued 3 April 2025, sets minimum risk management practices for what its Section 5 defines as high-impact AI — "AI with an output that serves as a principal basis for decisions or actions with legal, material, binding, or significant effect on" an enumerated list running from civil rights, civil liberties and privacy through human health and safety to critical infrastructure. Human oversight, intervention and accountability is one of those practices, alongside pre-deployment testing, an impact assessment, and ongoing monitoring. Inside such a use case, "an authorized person can log in and look at it" is thin. A state transition with a named actor is not.
Two details decide whether the gate is real. A confirmation must capture what the person saw — identity, timestamp, the evidence rendered to them — not merely that they clicked, or a later reviewer cannot tell whether the approver read the source span or a summary. And the rejection rate is an instrument: a gate that has never rejected anything is a click, not a control.
Reversibility means append and supersede, never overwrite
Corrections are new rows pointing at what they replace. The prior assertion stays, stays queryable, stays attributed. This is the 21 CFR 11.10(e) clause turned into a schema, and it is the right schema whether or not that regulation reaches you.
Temporal modeling is standardized and under-used. SQL:2011 (ISO/IEC 9075:2011) added application-time period tables — valid time, when a fact was true in the world — and system-versioned tables declared with PERIOD FOR SYSTEM_TIME and WITH SYSTEM VERSIONING, giving transaction time and FOR SYSTEM_TIME AS OF point-in-time queries. Together they are bitemporal. You need both to answer the question that shows up in a dispute: not "what does the record say?" but "what did it say on the day the decision was made, and when did we learn otherwise?"
The harder half of reversibility sits outside the database. A value already read downstream cannot be un-read. Reversal is a compensating event other systems have to receive and act on, so it has to be designed alongside the action, not discovered after the first bad batch. If nothing downstream can consume a retraction, the write path is not reversible. Put it in the first design review: when we get this wrong for 10,000 records, what puts it right, and who executes it?
Treat model output as untrusted input
NIST SP 800-53 Rev. 5 SI-10 covers information input validation — checking the syntax and semantics of system inputs, including character set, length, numerical range and acceptable values, against specified definitions of format and content. Model output arriving at a record system is input, and gets the same treatment as anything else off the wire: schema and enum validation, referential checks against the target system's own keys rather than the model's belief about them, cross-field consistency rules, and rejecting rather than coercing. Schema validity is not evidence — a well-formed invented date passes the parser and lands in storage, which is worse than malformed output, which stops at the gate. More in the piece on extraction versus generation.
The permission surface matters as much as the validation. The service principal performing AI writes should hold grants to a narrow field set on a narrow table, not the grants a human administrator carries. Rate limits belong at the gateway. A kill switch should be a configuration flag read at request time, not a redeploy — the moment you need it is the moment a deploy pipeline is the last thing you want in the path. And if the model reads customer-supplied documents on the way to a write, those documents are part of the threat surface — a prompt-injection problem with database consequences.
Why the integration design outranks the model choice
Stated plainly: if the boundary is designed well, the record system does not know or care which model produced a value. It knows the shape of an assertion, the states it can occupy, and the transitions between them. Swapping a small local model for a frontier one becomes a configuration change rather than a migration. If the boundary is designed badly, a better model produces better-sounding rows that are still duplicated, still unattributed, still unreversible. The asymmetry is lifespan: you will replace the model, probably twice, before the system retires; the integration lives as long as the records do.
We design these boundaries the way we design any federal interface — contract-first, with an OpenAPI 3.1 specification written and reviewed before the code, contract tests running against it in CI, a documented error envelope, an explicit deprecation policy, and authentication matched to the consumer class. That is where rate limiting and the kill switch live. We instrument the path like any production service — OpenTelemetry traces, structured logs, metrics — so "which run wrote this row" is answerable from observability as well as from the row.
What we build here, and what we decline
Precision Federal builds the integration layer: the API contract between a model and the system that has to trust it, the validation and idempotency behavior at that boundary, the provenance and state columns underneath, and the observability that makes the path reconstructable. Our standard:
- Every AI-originated row carries source, producer version, run, actor, state and idempotency key — written in the same transaction as the value.
- Idempotency keys derive from the triggering business event, never from model output; key reuse with a different request fingerprint is an error, not a second write.
- Business state and its audit event commit together, via an outbox, and publish afterward.
- The confirmation gate is a data state enforced by the read view, not a screen — and the confirmation records what the reviewer was shown.
- Corrections append and supersede; no update path destroys a prior assertion.
- The compensating action is specified before the first write goes live, including who executes it and what downstream consumers do with it.
The refusals are the more useful half. We will not build a path that commits model output straight into an authoritative record with no confirmation state and no supersede path when that record is filed, signed, or acted on — not because models are careless, but because a value that cannot be reconstructed or retracted is not a record. We will not accept "the model is accurate enough to skip the gate" as a requirement; accuracy is a measurement on a sample, the gate is a property of the system. We do not issue ATOs, and will never describe anything we build as arriving pre-accredited, because nothing does — authorization is a decision an authorizing official makes about a system in its environment. We are not a C3PAO and cannot assess anyone for CMMC. We do not perform an independent assessment and then remediate our own findings. We hold no facility clearance today and do not perform classified work on classified networks. And we do not author your records schedule — that belongs to your records officer and your counsel, and we build to the schedule we are given. The longer version: what we build and what we decline.
Common objections
Our model is accurate enough that the confirmation step is pure overhead.
Accuracy is a measurement on a sample; the gate is a property of the system, and the two answer different questions. Even at a low error rate, the state machine is what gives you a place to stand when something does go wrong — a population to scope, a prior value to restore, an actor to attribute. Removing it does not raise throughput much either, because the expensive part is reviewer attention rather than the transition. What usually helps is confirming at a coarser or finer granularity, or routing high-confidence categories to a lighter review — not deleting the state.
We already log everything. Isn't that the audit trail?
Application logs and a record's provenance are different artifacts with different lifespans. Logs are typically retained for weeks, are not transactionally consistent with the write, and are usually mutable by anyone with production access. A record retained under a NARA-approved schedule may outlive the logging platform by a decade. If the only place a value's origin exists is a log line, the record loses its provenance at the first retention rollover — and the correlation is by timestamp, which is exactly the kind of join that fails under retries.
Does this mean a human has to touch every single row forever?
No, and pretending otherwise would be a different failure. The state machine is the mechanism; the policy for who or what performs the promotion is a separate decision that can vary by field, by confidence, by consequence. Some categories can be auto-promoted under a documented rule with sampling-based review behind it. What should not vary is that the promotion is an explicit, attributed, reversible transition — so that when the auto-promotion rule turns out to be wrong, you can name every row it touched and put them back.
Frequently asked questions
It is a client-generated value the server stores alongside the request fingerprint and the outcome, so a repeated request returns the original outcome instead of writing again. AI pipelines need one because their writes are creations rather than replacements — POST semantics, which RFC 9110 does not classify as idempotent — and because queues and orchestrators deliver at least once by design. Derive the key from the triggering business event, never from the model's output.
At minimum: the source record identifier and offsets, the producing model's name and version and configuration hash, a run identifier, separate columns for the asserting service principal and the confirming person, a state value, a pointer to any assertion it supersedes, and the idempotency key. The W3C PROV model is a useful checklist for whether the set is complete, and NIST SP 800-53 Rev. 5 AU-3 and AU-10 describe what a reviewer will expect to reconstruct from it.
Because everything that is not the user interface bypasses it — batch jobs, partner integrations, retries, maintenance scripts. If the gate is a state in the data and the authoritative read view returns only confirmed rows, it is enforced by the same machinery that enforces the rest of your integrity constraints, and "can this be bypassed?" becomes a mechanical question rather than a policy one.
Append and supersede rather than update, so the prior assertion remains queryable and attributed — the design 21 CFR 11.10(e) states as a rule for audit trails. Model both valid time and transaction time if you need to answer what the record said on a past date; SQL:2011 standardized both. Then design the compensating event for downstream consumers at the same time as the write itself, because a value that has already been read cannot be un-read.
For the integrity of the record, yes. A stronger model raises the quality of proposed values, which is worth having, but it does not deduplicate a retry, attribute an assertion, or make a bad batch reversible. Those are properties of the boundary. Design the boundary so the record system is indifferent to which model sits behind it, and model selection becomes a change you can measure and roll back instead of a commitment.