Evidence-Driven Engineering: Govern the Proof, Not the Thinking
Evidence-Driven Engineering: Govern the Proof, Not the Thinking
One of the biggest mistakes we can make with AI engineering is trying to govern every move an agent makes.
More rules. More files. More instructions. More policies. More architecture.
Eventually the agent spends more time navigating governance than solving the problem.
There is a simpler model:
Let the agent work freely inside the boundary. Require it to emit evidence when meaningful work is completed.
That shifts governance away from controlling reasoning and toward proving outcomes.
The Method
The pattern is simple:
Intent
↓
Agent / Developer / Workflow
↓
Work
↓
Emit Evidence
↓
Validate
↓
Persist
↓
Measure / Audit / Learn
The agent can choose how to reason, plan, explore, or implement.
But if it wants its work to count, it must produce a standard evidence message.
That evidence becomes the price of participation.
A Shared Evidence Skill
Instead of every repo inventing its own logging and audit approach, provide a reusable skill:
.claude/
└── skills/
└── emit-evidence/
├── SKILL.md
├── schema.json
└── emit.py
The skill answers three questions:
When must evidence be emitted?
What must the evidence contain?
How is it emitted?
Every agent uses the same contract.
A simple event might look like this:
{
"event_id": "evt_abc123",
"timestamp": "2026-10-20T08:55:01Z",
"repo": "customer-service-api",
"intent_id": "INT-042",
"actor": "claude-code",
"action": "implemented",
"result": "success",
"evidence": {
"tests_run": 18,
"tests_passed": 18,
"files_changed": 3,
"commit": "7fd8c21"
}
}
Nothing fancy.
Just enough to answer:
What happened?
Who or what did it?
What intent was being satisfied?
What was the result?
Where is the proof?
Skills Emit. Hooks Verify.
This is an important distinction.
The skill provides the shared behavior:
emit_evidence(event)
The agent says:
I completed the work, and here is the evidence.
A deterministic hook then verifies that the required evidence exists and conforms to the schema.
Agent
↓
Evidence Skill
↓
Evidence Event
↓
Validation Hook
↓
Accepted / Rejected
The agent gets freedom.
The system gets deterministic verification.
That is a much healthier boundary than trying to specify every step the agent must follow.
Where Does the Evidence Go?
Start locally.
evidence/
├── runs/
│ └── 2026-10-20T085501Z-abc123.json
└── index.jsonl
That is enough for a proof of concept.
But the emitter should not care about the final storage technology.
Over time the same interface can route evidence elsewhere:
emit_evidence()
│
├── Local JSON
├── PostgreSQL
├── S3
├── EventBridge
├── Kafka
└── Enterprise Evidence Service
The repository owns producing evidence.
The enterprise platform owns persistence, retention, aggregation, reporting, and audit.
That separation matters.
It means teams can start small without redesigning the system when enterprise requirements arrive.
Governance Becomes Much Smaller
Traditional governance often tries to prescribe behavior:
Use this workflow.
Use this agent.
Use this model.
Follow these steps.
Create these files.
Call these tools.
Reason this way.
Evidence-driven governance asks something different:
What outcome were you trying to achieve?
Were you authorized to do it?
Did you achieve it?
Prove it.
That gives us a compact governance model:
Intent — what must become true.
Authority — what the participant is allowed to do.
Execution — freedom inside the boundary.
Evidence — proof of what actually happened.
Validation — deterministic verification.
Persistence — organizational memory.
The Enterprise Architecture
The larger architecture becomes surprisingly straightforward:
ENTERPRISE INTENT
│
▼
Work / Request
│
▼
Agent / Human / System
│
▼
Execution
│
▼
SHARED EVIDENCE SKILL
│
▼
Evidence Event
│
Schema Validation
│
▼
Evidence Platform
┌───────────┼───────────┐
▼ ▼ ▼
Storage Metrics Audit
│ │ │
└───────────┼───────────┘
▼
Proof of Value
Now architecture, governance, observability, and value measurement start connecting.
The same evidence used to prove that a feature works can later help answer:
Which agents are producing reliable outcomes?
Which repositories generate the most failed validations?
How much work is being automated?
Which intents produce measurable business value?
Which models or workflows are most effective?
Where are governance violations occurring?
What actually happened during an incident?
We are no longer collecting logs simply because logs are expected.
We are building an evidence trail around intent.
The Principle
The underlying rule is very simple:
Do not govern how an intelligent system thinks more than necessary. Govern what it is allowed to do, and require proof of what it actually did.
In Intent-Driven Engineering, the human establishes the intent and boundaries.
The agent determines how to accomplish the work.
The system validates the result.
And every meaningful participant leaves evidence behind.
That may be one of the simplest governance models available for agentic engineering:
Skill = shared behavior.
Schema = shared language.
Hook = enforcement.
Store = organizational memory.
Evidence = proof.
Or even shorter:
If you want to play in the system, emit evidence.
That is governance without smothering intelligence.
Comments