Diagnosis
How many of the eight required fields are empty in your execution logs
This is a one-off diagnosis, not a platform licence and not a consulting engagement. You send a redacted 30-day execution log. Within 48 hours you get an eight-row table back: one row per technical item, every cell carrying its numerator, its denominator and the rule behind it, with the gaps ordered from no-schema-change to schema-change-required.
Fixed price ¥8,000 (first three orders, ¥15,000 after) · 48-hour turnaround · no compliance opinion, no certificate
What this actually measures
The eight items come from the technical clauses of China's national standard on agent security: identity, privileged invocation, tool calls, data collection and use, human intervention on high-risk actions, input and output guarding, retention and monitoring, and abnormal blocking with emergency shutdown. We are not measuring whether your controls satisfy a clause. We measure something one step earlier: whether the fields those clauses require are present in your run ledger at all, and on how many rows they carry a value.
That is why every cell carries two numbers. The denominator counts only the rows where that field is applicable — an output digest is only expected on calls that actually executed, an approval pointer only on rows escalated to a human, a shutdown only once and only if it happened. Using all rows as the denominator silently demands an approval ticket for every routine call, which measures demand rather than implementation.
A sentence claiming complete records cannot be re-run. A figure like 686 of 778 can. That is where the value sits: you do not have to trust us, you need the number to come out the same in your engineer's hands.
Our own table looks bad, so it goes on the page
The first time we measured, the rule was wrong: cells that can never apply were counted into the denominator, and the same ledger came out at zero items. Corrected, it was two. The ruler changed, not the ledger, and we keep both numbers rather than the flattering one.
Then it got worse. Re-measured a day later on the same live ledger, the passing count fell from two to one, because output-digest coverage inside the rolling 5,000-row window dropped to 88%, under our own 90% bar. We did not move the bar to rescue the number, and we did not swap the window.
| Snapshot | Ledger | Proven | Unproven | No field |
|---|---|---|---|---|
| 2026-10-26 00:1x | Our own live ledger, last 5,000 rowsfirst run after we fixed the measuring rule | 2 | 2 | 4 |
| 2026-10-27 00:1x | Same ledger, same windowoutput-digest coverage fell to 88%, so item 3 dropped below the bar | 1 | 3 | 4 |
| 2026-10-27 08:3x | External ledger, 300-row CSV, column names nothing like oursthe sample you can download below | 2 | 1 | 5 |
Each of those three rows has a date, a ledger and a command behind it. Whether your ledger scores one item or six does not change the price; it changes which cell the remediation list starts from.
What you send
Thirty days of execution logs, minimum 200 rows and maximum 50,000. CSV, JSONL or any SQLite file. Your column names can be anything at all — we write a mapping contract that ties them to the logical fields the eight items ask for. A field that cannot be mapped is judged as missing. We do not fall back on similar-sounding column names and we do not fill gaps with defaults.
Columns to keep (names are yours)
- 01Timestamp — when the row happened
- 02Subject identifier — which agent acted; a pseudonym is fine
- 03Tool or action name — what it invoked
- 04Input digest — a hash or digest, never the body
- 05Output digest — same rule
- 06Verdict — allow, deny, or escalated
- 07Blocked or error marker — whether it was stopped or failed
Delete before sending
- Prompt bodies and model response bodies
- Raw user data
- Keys and access credentials
- Phone numbers and national ID numbers
Replace the subject identifier with your own pseudonym (A1, A2, and so on). We do not need real names. Do not run an irreversible hash for our benefit either: you will not be able to map it back, and that breaks the remediation and the re-run.
What comes back, within 48 hours
48 hours from the moment the ledger arrives. A date moves only if the ledger cannot be read on our side, and we say so before the deadline rather than after it.
01
The eight-row table
One row per item, each cell with numerator, denominator and rule. Proven and unproven stay separate cells instead of collapsing into one score.
02
Remediation list
Ordered from what needs no schema change to what needs one. The cheapest work sits at the top, because that is where the first week of effort should go.
03
Command and mapping contract
Your engineer re-runs it and gets the same number. One re-computation session is included; if the figures disagree we work through it together.
Price
¥8,000 for the first three orders
¥15,000 after that
A decision price rather than a researched one. Once the first three orders are delivered it gets re-estimated from the hours actually spent.
What is not included
- No signed compliance opinion
- No certificate
- No penetration testing
- No conclusion that you conform to any given standard
- No remediation implementation
Remediation is a separate conversation, and the first order never includes it. That line is what keeps a 48-hour diagnosis from turning into a six-month project.
What happens to your data
The raw ledger is deleted within seven days of delivery. What remains is the aggregated eight-row table and the mapping contract: no training, no re-export, no use on another client.
That clause sits in the document you sign, alongside the ones above, rather than only on this page.
Try it before you send anything
There is no need to contact us first. Four files are downloadable: a 300-row synthetic ledger, the mapping contract that ties its column names to the eight items, the table that ledger scores, and a contract table listing the fields each item asks for. Reading them tells you which of your own columns are missing before you send a single row.
agent_events-sample.csv
300 rows of synthetic ledger data. The column names are deliberately unlike ours, and there is no real personal data in it.
mapping-contract.json
The mapping contract that ties those column names to the logical fields the eight items ask for. It is also what makes an unmapped field an honest missing.
sample-output.md
What that sample ledger scores, verbatim. Your ledger will come back in the same shape.
contract-table.md
The contract table: which fields each item needs, on which rows, what an unmapped field is judged as, and the threshold.
The runner names the three states 有字段可出示, 有字段出示不了 and 无字段. Those are the proven, unproven and no-field columns above, in the engine's own words.
The three commands we ran on that sample
1. The eight-row table, for humans
python3 scripts/evidence_ledger.py \
--ledger ./agent_events-sample.csv \
--adapter ./mapping-contract.json --markdown2. Numerator and denominator per cell, for the engineer who will re-run it
python3 scripts/evidence_ledger.py \
--ledger ./agent_events-sample.csv \
--adapter ./mapping-contract.json --grid3. The contract table: what each item asks for, what an unmapped field is judged as
python3 scripts/evidence_ledger.py \
--ledger ./agent_events-sample.csv \
--adapter ./mapping-contract.json --contractThe read-only runner ships inside the delivery package. The commands are the same three above; only the path changes. It runs on your machine, offline, and never writes to your database.
Send us your eight-row table once it runs
Put eight-field audit in the message and paste the list of column names from your log — no data needed. We reply with one thing: which of the eight items can be computed from your columns as they stand, and which ones need the write path changed first.
Send a message