In code, this is what it looks like.
An abridged module schema with one entity, three states, an actor-agnostic activity, a confidence threshold, and the history-event shape.
{
"module": "leave_application",
"entity": "LeaveApplication",
"states": ["Draft", "Submitted", "Approved", "Confirmed"],
"activities": [
{
"name": "submit",
"actor": "any",
"from": "Draft",
"to": "Submitted",
"form": {
"fields": [
{ "name": "start_date", "type": "date", "required": true },
{ "name": "end_date", "type": "date", "required": true },
{ "name": "reason", "type": "string" }
]
},
"confidence_threshold": 0.85
}
],
"history_event": {
"by": { "type": "actor_ref" },
"on": { "type": "timestamp" },
"changes": { "type": "field_diff[]" },
"ai": {
"type": "object",
"fields": ["reasoning", "sources", "model", "model_version", "prompt_hash", "confidence"],
"optional": true
}
}
}
The schema above is the operational source of truth. A human submitting the form through the browser, Claude submitting it through MCP, and GPT-5 submitting it through MCP all hit the same code path. They all produce the same history event. The audit can be queried with one query.
This is what externalizing operational intelligence into persistent schemas means in practice.
→ See the full schema