Transformation record: the call behind the essay
One verified call in full: input, output, request, receipt and the verifier's answer, on the same page. The essay What did it leave out? makes one argument: a transformation that deletes can be checked against its source, and the receipt reports how much of the meaning survived. This page is the evidence behind it, in the order it was produced. The input is a memo written for the essay. It is a composite, not a customer story. It appears here in full and unedited. 2344 characters. Every byte below is what the call received. 1743 characters. Read it against the input above: nothing was added, about a quarter was removed, and the words that remain appear in the same order as the source. Mode and ratio are the hint. The receipt reports what the engine actually did with them. Returned with the compressed text. The call asked for 0.7 and returned 0.7436. It did not get there in one pass: the first attempt came out at 0.7009, the fidelity gate refused it, and the engine relaxed the target by 1 step and kept more text. The receipt reports both attempts, so a reader can see that the realized ratio is fatter than the request rather than discovering it from the numbers. The quality block describes the pass that was accepted. Fidelity 0.983 is the mean entailment posterior over the windows checked, 0.9317 is the worst window, and 0 of 29 windows fell below the threshold. Coverage is 1.0, meaning every part of the input was visited. Protection pins stopped MODALITY 11, NEGATION 16, NUMERIC 15, REGISTER 1, TEMPORAL 7 markers from being deleted; containment holds, The models are pinned by hash rather than by name: llmlingua_q8 Neither number is a certificate of correctness. They measure how much of the source's meaning survived the deletion, not whether the surviving meaning was the part that mattered. The essay is about that gap. Two ways, neither needing an account or an API key. Hosted. Send the receipt with Offline. Canonicalise the receipt JSON with Operational reference: the docs. Files served next to this page, byte for byte: request.json, input.txt, output.txt, response.json, verify-request.json, verify-response.json.what value mode verifiedtarget ratio 0.7input 2344 characters, sha256 a43cd6faa364814b3625e12a32a40465da55e0350200fde6c97c46017762094doutput 1743 characters, sha256 e1d3f7a1db9f510bc4d5f9ad2a8308278c5b510c3004364cfb83e98d15d0e248realized ratio 0.7436first attempt rejected relaxed_ratio 0.7009, relax_steps 1fidelity score 0.983worst checked window 0.9317windows below threshold 0 of 29coverage 1.0output is a byte subsequence truesigning key key_id e6b78dfecceaverifier verdict valid: true, signature_valid: true, output_is_subsequence_recomputed: trueThe input
Incident memo: ticket 4471, vendor onboarding agent.
On 3 November an onboarding agent approved a supplier after screening. The context handed to the agent had been assembled from four sources: the supplier registration form, the sanctions screening result, two emails from the procurement officer, and a summary of the earlier correspondence. The registration form listed a trading address in Dubai. The screening result was clear. The summary, written eleven days earlier, described the beneficial owner as a resident of Cyprus; the screening record, refreshed the previous night, placed him in a jurisdiction under review. The agent approved. The reviewer who signed off an hour later had the same summary in front of her and no way to tell when it had been produced.
The failure was not in the screening service, which returned a correct and current result. It was in the assembly step: the summary was dense, accurate when written, and stale at the moment of use. Nothing in the record distinguished the two. The approval was reversed the following morning by a manual review, before any payment was released, and no loss resulted. The timeline below is reconstructed from the message queue.
Timeline. 08:12 the screening refresh completes. 08:14 the assembly job builds context and compresses each source. 08:14 to 08:16 the agent reads 1,842 tokens and returns an approval. 09:31 the human reviewer signs. 10:05 a second screening refresh lands. Next morning, a compliance analyst reads the refreshed record and reverses the decision.
What the evidence showed. The summary was the only source mentioning the beneficial owner's residence, and it was the oldest. The compressed version of the refresh arrived after the summary in the context window; the agent weighted the earlier statement, which was more specific. The assembly job kept no copy of the assembled context and wrote a ratio and a duration to its log. The reviewer asked for the text the agent had seen; it no longer existed.
Recommendations. First, every assembled context must carry the vintage of each source and must not be compressed into a single undifferentiated block. Second, the last compression before an irreversible action must produce a record that a third party can check. Third, the reviewer must see the same bytes the agent saw, not a summary of them.The output
Incident memo: ticket 4471, vendor onboarding agent.
3 November agent approved supplier after screening. context assembled from four sources: supplier registration form, sanctions screening result, two emails procurement officer, summary earlier correspondence. registration form listed trading address Dubai. screening result clear. summary, written eleven days earlier, described beneficial owner resident of Cyprus; screening record, refreshed placed jurisdiction under review. agent approved. reviewer signed hour later had same summary no way tell when produced.
failure not screening service, returned correct current result. assembly step: summary dense, accurate stale moment use. Nothing record distinguished two. approval reversed morning manual review, before any payment released, no loss resulted. timeline reconstructed message queue.
Timeline. 08:12 screening refresh completes. 08:14 assembly job builds context compresses each source. 08:14 to 08:16 agent reads 1,842 tokens returns approval. 09:31 human reviewer signs. 10:05 a second screening refresh lands. Next morning, compliance analyst reads refreshed record reverses decision.
evidence showed. summary only source mentioning beneficial owner's residence, oldest. compressed version refresh arrived after summary context window; agent weighted earlier statement, more specific. assembly job kept no copy assembled context wrote ratio duration log. reviewer asked text agent seen; no longer existed.
Recommendations. every assembled context must carry vintage each source must not compressed single undifferentiated block. last compression before irreversible action must produce record third party can check. Third, reviewer must see same bytes agent saw, not summary.The request
{
"squeeze_mode": "verified",
"target_ratio": 0.7
}The receipt
integrity anchors the two texts by hash, headline reports the realized ratio, quality reports what survived, and the signature covers the whole object.{
"headline": {
"squeeze_mode": "verified",
"ratio": 0.7436
},
"integrity": {
"raw_sha256": "a43cd6faa364814b3625e12a32a40465da55e0350200fde6c97c46017762094d",
"output_sha256": "e1d3f7a1db9f510bc4d5f9ad2a8308278c5b510c3004364cfb83e98d15d0e248",
"output_is_subsequence": true
},
"quality": {
"fidelity_score": 0.983,
"min_window_posterior": 0.9317,
"relaxed_ratio": 0.7009,
"relax_steps": 1,
"coverage_fraction": 1.0
},
"counts": {
"pins_protected": {
"MODALITY": 11,
"NEGATION": 16,
"NUMERIC": 15,
"REGISTER": 1,
"TEMPORAL": 7
},
"windows_total": 29,
"exact_matches": 4,
"windows_below_threshold": 0
},
"debug": {
"model_registry": {
"llmlingua_q8": "6c9a3a1ecbd8fdd12bb12c5592df5e99a2637403f3f48a50a1a2660056122f2f",
"llmlingua_tokenizer": "3a56def25aa40facc030ea8b0b87f3688e4b3c39eb8b45d5702b3a1300fe2a20",
"nli_q8": "9a83251a7d2ad82cd11172ba53ff240f26bf2c1038299787c082c3106e02b5b0",
"nli_tokenizer": "ff6f6cebf55bcccc4a80b52e956f16ae9d11b0bad02c7db4e7b36975488bf840"
}
},
"key_id": "e6b78dfeccea",
"receipt_signature": "569fa59771ecc27f9751bb2f9fcdb893e768cb464de91336397849b6e5eb4d223839a757cee7ae2885223918ff77a7aadfe718371cf21b1cc04f739c99a5650d"
}The verifier's answer
POST /v1/receipts/verify was given the receipt, the input and the output, and nothing else. It recomputed the hashes, the ratio and the containment relation, then checked the signature against the published key.{
"input_checks": {
"compression_ratio_recomputed": 0.7436006825938567,
"output_is_subsequence_recomputed": true,
"output_sha256_match": true,
"provided": true,
"ratio_matches_claim": true,
"raw_sha256_match": true,
"subsequence_matches_claim": true
},
"key_id": "e6b78dfeccea",
"key_id_known": true,
"signature_valid": true,
"valid": true
}What the engine did
output_is_subsequence is true.6c9a3a1ecbd8..., llmlingua_tokenizer 3a56def25aa4..., nli_q8 9a83251a7d2a..., nli_tokenizer ff6f6cebf55b.... A record that names a model without its artifact hash cannot be replayed.How to check it yourself
raw_input and compressed_output to POST https://macs.nanotoll.dev/v1/receipts/verify. It recomputes both hashes, the ratio and the containment relation, and verifies the signature. The answer is the object printed above.key_id and receipt_signature removed, object keys recursively sorted and compact separators, then verify the Ed25519 signature against the public key published at https://nanotoll.dev/.well-known/nanotoll-verify.json. The key's SHA-256 fingerprint is published in the DNS TXT record _nanotoll-verify.nanotoll.dev, so the key does not have to be taken on trust either. This runs without contacting the service.Reproduce it
curl -s -X POST https://macs.nanotoll.dev/v1/receipts/verify \
-H "Content-Type: application/json" \
-d @verify-request.json
sha256sum input.txt output.txtFor agents
endpoint: POST https://api.nanotoll.dev/v1/compress
auth: Authorization: Bearer *** (register: POST /api/v1/register)
modes: squeeze_mode = deterministic | extractive | verified
delete-only: all modes; receipt.integrity.output_is_subsequence is false when
the tabular-JSON reform rewrote structure (l2_skipped)
pricing: flat per call, prepaid USDC on Base - live values: GET /v1/limits
response: {"compressed": "...", "receipt": {...}}
check: POST /v1/receipts/verify with receipt + raw_input + compressed_output
recomputes hashes, ratio and containment; no key required
public key: GET /.well-known/nanotoll-verify.json
limits/caps: GET /v1/limits
billing: a call that fails or exceeds its caps is not billed