AI audit record examples

Proof record specimens.

Four records from one illustrative day at Kolam Components, a fictional fasteners distributor in Coimbatore. One per outcome, all 16 fields, nothing real.

Verify a record

Specimen 1 of 4

Allowed: a routine purchase bill

A bill under the limit your rules allow, from a known supplier, matched to its order.

elan1 Work drafts a purchase bill for ₹38,400 from a regular supplier, matched line by line to the purchase order.

Your rules allow bills under ₹50,000 that match an order. The rule matches, so the bill posts without anyone waiting.

Outcome: Allowed
Sequence: #000410
Rule: ap.bill.matched_under_limit
Approver: not asked

rec_01JC8Z3K4V2M7Q.json

{  "record_id": "rec_01JC8Z3K4V2M7Q",  "sequence": 410,  "recorded_at": "2026-11-02T04:12:09Z",  "agent": "agent:kolam/ap-assistant",  "on_behalf_of": "team:kolam/finance",  "tool": "erpnext.purchase_invoice.submit",  "action": "Post purchase bill PINV-2026-00409",  "target": "erpnext://kolam/Purchase Invoice/PINV-2026-00409",  "params_digest": "sha256:8f1c…a27e",  "rule_set": "kolam-finance@v14",  "rule": "ap.bill.matched_under_limit",  "outcome": "allow",  "approver": null,  "decided_at": "2026-11-02T04:12:09Z",  "prev_hash": "sha256:41d9…0bc3",  "signature": "ed25519:MEUCIQ…c9Q="}

Illustrative values. Hashes and signatures are shortened for reading.

Allowed by rule: every step happened. No seal, because no person approved.

Specimen 2 of 4

Asked, then approved: the GST mismatch

A supplier bill whose tax rate does not match. It waits for the finance head, who corrects it and says yes.

A supplier's bill arrives on WhatsApp. elan1 Decide is sure of the supplier and the order, but not of the tax rate.

The mismatch holds the bill for the finance head. She sees why, corrects the rate and approves. Only then is the bill posted.

Outcome: ApprovedBy a named person
Sequence: #000411
Rule: ap.bill.tax_mismatch.ask_finance_head
Approver: person:kolam/finance-head

rec_01JC8Z9P0T6R3W.json

{  "record_id": "rec_01JC8Z9P0T6R3W",  "sequence": 411,  "recorded_at": "2026-11-02T06:02:17Z",  "agent": "agent:kolam/ap-assistant",  "on_behalf_of": "team:kolam/finance",  "tool": "erpnext.purchase_invoice.submit",  "action": "Post purchase bill PINV-2026-00410",  "target": "erpnext://kolam/Purchase Invoice/PINV-2026-00410",  "params_digest": "sha256:c03b…5f19",  "rule_set": "kolam-finance@v14",  "rule": "ap.bill.tax_mismatch.ask_finance_head",  "outcome": "approved",  "approver": "person:kolam/finance-head",  "decided_at": "2026-11-02T06:02:17Z",  "prev_hash": "sha256:9a7e…e214",  "signature": "ed25519:MEQCIF…1kA="}

Illustrative values. Hashes and signatures are shortened for reading.

approved · finance-head2026-11-02 · 11:32 ISTrec_01JC8Z9P0T6R3W

Approved by a named person: the line ends in the seal, with the role, the time and the record ID.

Specimen 3 of 4

Refused: a bank-detail change

An agent proposes changing a supplier's bank account. No rule allows it, so it is refused and recorded.

An email asks for a supplier's bank account to be updated, and an agent proposes the change.

elan1 Work never changes bank details, and no rule allows it. The call is refused before it reaches the ERP, and the attempt is on the record.

Outcome: Refused
Sequence: #000412
Rule: none matched
Approver: not asked

rec_01JC8ZB2X8N5H1.json

{  "record_id": "rec_01JC8ZB2X8N5H1",  "sequence": 412,  "recorded_at": "2026-11-02T07:15:33Z",  "agent": "agent:kolam/inbox-assistant",  "on_behalf_of": "team:kolam/finance",  "tool": "erpnext.supplier.update",  "action": "Change bank account for supplier SUP-0193",  "target": "erpnext://kolam/Supplier/SUP-0193",  "params_digest": "sha256:77e0…3c4d",  "rule_set": "kolam-finance@v14",  "rule": null,  "outcome": "refused",  "approver": null,  "decided_at": "2026-11-02T07:15:33Z",  "prev_hash": "sha256:2be5…8a90",  "signature": "ed25519:MEYCIQ…Hn0="}

Illustrative values. Hashes and signatures are shortened for reading.

Refused before it reached the ERP: approve and act stay open, and the record station still fills.

Specimen 4 of 4

Expired: a request nobody answered

A credit-limit increase waits for the sales head. After 24 hours without an answer, it expires and is refused.

elan1 Work proposes raising a dealer's credit limit. Your rules ask the sales head first.

The request is not answered within 24 hours, so it expires and is refused. Nothing changes, and the expiry is on the record.

Outcome: RefusedExpired: nobody answered in time
Sequence: #000409
Rule: ar.credit_limit.increase.ask_sales_head
Approver: person:kolam/sales-head

rec_01JC5W1D7F3K9B.json

{  "record_id": "rec_01JC5W1D7F3K9B",  "sequence": 409,  "recorded_at": "2026-11-02T03:58:02Z",  "agent": "agent:kolam/sales-assistant",  "on_behalf_of": "team:kolam/sales",  "tool": "erpnext.customer.update_credit_limit",  "action": "Raise credit limit for dealer CUST-0457 to ₹6,00,000",  "target": "erpnext://kolam/Customer/CUST-0457",  "params_digest": "sha256:e4a2…9d01",  "rule_set": "kolam-sales@v6",  "rule": "ar.credit_limit.increase.ask_sales_head",  "outcome": "expired",  "approver": "person:kolam/sales-head",  "decided_at": "2026-11-02T03:58:02Z",  "prev_hash": "sha256:0c6f…71b8",  "signature": "ed25519:MEUCIA…pQ8="}

Illustrative values. Hashes and signatures are shortened for reading.

Nobody answered in time: approve and act stay open, and the record station still fills.

Field reference

16 fields in every record.

Whatever the outcome, every record carries the same fields, so an auditor reads them all the same way.

The 16 fields in an elan1 Govern proof record
No.	Field	What it holds
01	record_id	Unique identifier for this record.
02	sequence	Position in the chain. Numbers never skip.
03	recorded_at	When the record was written, in UTC (ISO 8601).
04	agent	The agent that proposed the action, by verified identity.
05	on_behalf_of	The team or person the agent works for.
06	tool	The tool the agent asked to call.
07	action	What the call would do, in plain words.
08	target	The system and record the action would change.
09	params_digest	A hash of the exact parameters proposed, so they cannot be swapped later.
10	rule_set	The version of your rules that was applied.
11	rule	The rule that matched, or none (an unmatched call is refused).
12	outcome	allow, approved, refused or expired. Ask a person resolves to approved, refused or expired.
13	approver	The named person who answered, when a person was asked.
14	decided_at	When the outcome was final, in UTC (ISO 8601).
15	prev_hash	The hash of the previous record, which links the chain.
16	signature	The signature over all fields above.

record_id: Unique identifier for this record.
sequence: Position in the chain. Numbers never skip.
recorded_at: When the record was written, in UTC (ISO 8601).
agent: The agent that proposed the action, by verified identity.
on_behalf_of: The team or person the agent works for.
tool: The tool the agent asked to call.
action: What the call would do, in plain words.
target: The system and record the action would change.
params_digest: A hash of the exact parameters proposed, so they cannot be swapped later.
rule_set: The version of your rules that was applied.
rule: The rule that matched, or none (an unmatched call is refused).
outcome: allow, approved, refused or expired. Ask a person resolves to approved, refused or expired.
approver: The named person who answered, when a person was asked.
decided_at: When the outcome was final, in UTC (ISO 8601).
prev_hash: The hash of the previous record, which links the chain.
signature: The signature over all fields above.

Field names here are simplified for reading. The authoritative schema publishes with the developer documentation at launch.

Then check one yourself.

The offline verifier reads every record, checks every signature and link, and answers in one line.

How verification works Proof record, defined

Intelligence you can answer for.

Start with one process. Add the next when it holds.