Designed to be read, or built to be proved?
A policy proves intention. Training proves instruction. A committee proves structure. None of them prove that a particular use of a particular system was identified, assessed, monitored and controlled at the moment it mattered. That gap is only visible under pressure, and by then the record either exists or it does not.
Most frameworks are built to be read. Rather fewer are built to be proved.
The distinction that decides how a governance framework performs under scrutiny.Examine your own framework the way an opponent would
Not whether it appears sound. What evidence exists that it operated. These six questions are where most frameworks stop being able to answer, and each one has a technical answer rather than a documentary one.
| The question | What a framework usually offers | What EcoKure produces instead |
|---|---|---|
| What AI is actually in use across the business? | An approved-platform list, and an assumption that it reflects reality. | A record of every output that entered a verification lane, from whichever system produced it, including the ones nobody registered. |
| Who owned each material use? | A RACI matrix, maintained separately from the systems it describes. | Ownership attached to the workflow at the point of verification, so the record and the reality cannot drift apart. |
| Who had authority to stop it? | An escalation path in a document. | A fail-closed permission boundary that blocks the action, plus the identity of whoever released a hold and when. |
| What did the board understand, as distinct from what it was shown? | Board papers, summarised by the people being overseen. | Signed evidence packs the board can have examined independently, without relying on the summary or on the vendor. |
| Can you demonstrate the controls were operating, not merely designed? | Control descriptions, and periodic attestation that they exist. | Per-decision execution records: which lanes ran, what each returned, what was blocked, what abstained, and what was held. |
| Can a decision made two years ago be reconstructed? | Archived documents, and the hope that the reasoning is recoverable. | The sources, the AI output, the applicable control at that time, the human review and the final decision, replayable and cryptographically verifiable. |
The distinction that decides the answer
Designed and operating are different claims requiring different evidence. A framework demonstrates design. Only a per-decision record demonstrates operation, and it has to have been produced at the time. It cannot be assembled afterwards, which is precisely why it is worth something.
The hardest question, taken on directly
Reconstructing a decision made two years ago is the question most organisations cannot answer, because the pieces were never bound together at the time. EcoKure binds them at the moment the decision is made.
The boundary on this claim
Reconstruction applies to decisions that ran through this layer. EcoKure deterministically replays captured and versioned inputs, evidence, controls and execution paths. It cannot recreate a decision that was never captured, and it does not reproduce the internal behaviour of the model that produced an output. What it reconstructs is what was checked, under which rules, using which evidence, reviewed by whom, and what was permitted. Stated any more broadly than that, the claim fails the first time a technically competent person tests it.
Which layer answers what
Deterministic Taxonomy Lanes
Is this output or decision allowed?
DTL routes an output or decision into a defined verification lane, applies machine-readable rules, and returns a categorical result with the reasoning recorded. It does not score confidence. It decides, or it declines to decide.
DAXDeterministic Action Execution
Is this physical action allowed to happen?
DAX places a permission boundary between a decision and an action that affects hardware, machinery, infrastructure or another physical system. It is fail-closed: if the check cannot complete, the action does not proceed.
DCLADeterministic Control Lineage Architecture
The governing rules changed. What does that affect?
DCLA tracks changes to regulations, policies, controls and operating requirements, then identifies the systems, decisions, evidence and previous approvals that may need reassessment. Affected work is held rather than allowed to continue on a superseded rule.
DELADeterministic Evidence Lineage Architecture
The underlying evidence changed. What does that affect?
DELA detects changes in scientific, operational or other source evidence, traces the affected dependencies, preserves the work that remains valid, selectively replays reproducible operations, and routes non-reproducible work to qualified human review.
What this page is not
- It is not legal advice, and nothing here should be relied on as a statement of directors' duties or of the law in any jurisdiction. Take advice from your own counsel.
- It does not claim that using EcoKure discharges any obligation. Evidence supports a defence. It does not constitute one.
- It does not replace your governance framework. A framework is still required. This makes it provable rather than merely documented.
- EcoKure holds no certification and is early stage. We would rather you heard that here than found it in diligence.
Run the exercise on one workflow
Pick a decision your organisation made in the last two years that involved an AI output. Try to reconstruct it from the sources, the output, the review and the final call. Whatever you find, that is the conversation worth having.