# ERI Primer

## A developer's introduction to making consequence testable

Most software is built to answer a productive question:

> What should the system do?

That is necessary, but it leaves another question strangely soft:

> Under what conditions may this system cause an external effect at all?

An **Executable Reference Implementation (ERI)** exists to make that second question concrete, runnable, and checkable.

An ERI is not a new kind of application framework. It is a bounded software artifact that makes one important behavioral claim executable. It says, in effect: *within this defined scope, this action does not happen unless these conditions are true. Here is the code, the test path, and the evidence by which you can check that claim.*

That is the whole idea. Everything else follows from taking it seriously.

## Start with consequence, not features

Consider a system that can open a firewall port, release a model, approve a payment, or disclose regulated data. The feature is easy to describe: "send this request."

The consequence is harder:

- Who is allowed to make the request?
- What authority is current?
- Which policy applies now?
- What happens when one of those answers is missing?
- Can anyone later determine whether the effect occurred?

Conventional systems often spread those answers across documentation, dashboards, application code, logs, and human review. An ERI brings one consequential path into a small enough scope that the rule, decision, release, and evidence can be examined together.

The shift is from **"we have a policy"** to **"this execution is conditioned by that policy."**

## What makes something an ERI?

An ERI has a specific invariant: a statement that must hold inside its declared boundary.

For example:

> A firewall rule may be changed only when the request has verified authority, matches the active policy, and a durable decision record is prepared before release.

The ERI does not need to prove every fact about firewalls, identities, or cloud security. It needs to make that one claim precise and testable. A credible ERI normally has five qualities:

| Quality | Plain meaning |
|---|---|
| Bounded | It says exactly what is in scope, and what is not. |
| Explicit | The rule and inputs that drive the decision are named. |
| Repeatable | Under its declared conditions, the decision can be reproduced or replayed. |
| Fail-closed | If a required condition cannot be established, the action is not released. |
| Evidenced | It leaves enough durable evidence for someone else to inspect the decision and outcome. |

The word **reference** matters. An ERI is a reference point for a specific behavior, not a claim that an entire product, organization, or future release is certified.

## The execution boundary

The useful mental model is a boundary between a request and its consequence:

```text
proposal or request
        |
        v
verify required facts --> evaluate declared rule --> ADMIT, REFUSE, or ABORT
                                                     |
                                      only ADMIT can release an action
                                                     |
                                                     v
                                   independently observe terminal state
                                                     |
                                                     v
                                        bind evidence to the result
```

`ADMIT` means the defined conditions were established and the action may be attempted. It does not mean the target definitely changed.

`REFUSE` means a known requirement was not met. The action is not attempted.

`ABORT` means the system cannot safely establish a mandatory fact or complete the governed path. The action is not released.

This distinction matters because a decision is not the same thing as an external result. An action can be admitted and still fail downstream. A trustworthy record separates the **decision**, the **attempt**, and the independently observed **terminal state**: `COMMITTED`, `NO_COMMIT`, or `INDETERMINATE`.

## Why a refusal is a successful result

In an ordinary feature flow, a refusal can look like an error. In an ERI, refusal is often the proof that the rule is real.

If an authorization record is stale, a signature does not verify, a required dependency is unavailable, or the request falls outside the policy, the correct outcome is not a best-effort fallback. It is no release, with evidence explaining why.

That is what "fail closed" means. The ERI is designed so uncertainty cannot quietly become permission.

## ERI, ERIL, and CERI

These terms are related, but they are not interchangeable.

| Term | What it is | What it is not |
|---|---|---|
| **ERI** | A bounded, runnable reference implementation for a named behavioral claim | A whitepaper, demo, generic product label, or an automatic certification |
| **ERIL** | A semantic execution language for expressing whether a governed action is admissible before it runs | A general-purpose programming language or a replacement for application code |
| **CERI** | A phase-qualified ERI designation: a containerized package is an artifact; a *Certified* ERI is a separately earned conformance status | Proof that packaging alone equals certification |

ERIL is best understood as the rulebook at the execution boundary. Your application code can still calculate, query, render, or call services. ERIL asks the separate question: **may this particular execution happen?**

Here is an intentionally simplified illustration, not a normative syntax definition:

```eril
contract RegulatedDataAccess {
  require identity.verified
  require purpose.bound
  require authorization.current

  on_failure refuse_execution
  emit evidence
}
```

If every required condition is established, the boundary may release the action. If any required condition fails or cannot be verified, it refuses or aborts according to the declared rule. Either way, it records evidence.

## An ERI is not a demo with better logging

Several artifacts are useful, but they solve different problems.

| Artifact | Useful for | Missing from an ERI by itself |
|---|---|---|
| Design document | Explaining intent | Runtime enforcement and a replayable result |
| Demo | Showing a happy path | A bounded negative path and failure semantics |
| Test suite | Checking examples | The runtime boundary that prevents a prohibited effect |
| Audit report | Assessing prior behavior | A mechanism that conditions the next action |
| Log dashboard | Observing events | Proof that an action could not bypass the rule |

An ERI may include all of these. None of them, standing alone, makes the claim executable.

## A small example

Imagine an AI assistant proposes opening TCP port 8443 for a support task. The assistant might provide a confidence score, a rationale, an ethical review, and a structured request. Those are useful inputs, but they do not create authority.

An ERI for the release path could require:

1. A verified actor and valid authority for the target firewall.
2. A policy that allows TCP 8443 from the requested network and no broader source range.
3. An intact, fresh, non-replayed request.
4. A durable prepared evidence record before action release.
5. An independent check of the resulting firewall state.

If the assistant is highly confident but the authority is invalid, the correct result is `REFUSE`. If the evidence service is unavailable before release, the correct result is `ABORT` and `NO_COMMIT`. The assistant can propose; the boundary decides; the evidence records what happened.

This is also why ERIs work well with probabilistic systems. A model may be non-deterministic in how it proposes an action. The consequential gate does not have to be. The invariant belongs at the point where the external effect is released.

## How to begin an ERI

Do not start by trying to make an entire platform into an ERI. Start with one effect that matters.

1. Name the effect: *What could change outside the system?*
2. Write the invariant: *What must be true before it is released?*
3. Bound the environment: *Which identities, policy version, dependencies, target, and failure modes are included?*
4. Define failure: *Which conditions produce `REFUSE`? Which produce `ABORT`?*
5. Define evidence: *What must be preserved to replay the decision and observe the terminal state?*
6. Add negative controls: *How will you show that mutation, replay, missing proof, or an unavailable dependency does not produce release?*

If any one of those cannot be stated, the work may still be a useful prototype or candidate, but it is not yet an ERI claim.

## Evidence strength is not a marketing ladder

An identifier, a document, a local passing test, a controlled cloud run, and a witnessed end-to-end proof run are different kinds of evidence. They should not be collapsed into one word such as "certified."

NovaFuse uses an evidence progression from `E0` (an assertion or referenced identifier) through `E5` (qualified external reliance). `E1` means a native specification has been located and integrity-recorded; it does **not** mean the capability has been executed or certified. A claim must not exceed the strongest evidence preserved for that exact identifier, version, environment, and proof run.

This is not caution for its own sake. It keeps a promising candidate from carrying claims earned only by an adjacent component, old run, or unpinned build.

## The one sentence to keep

> An ERI makes a bounded rule about consequence executable: it determines whether a specific action may occur, fails closed when proof is missing, and leaves evidence that lets others check the result.

That is why ERIs exist. They turn consequential system behavior from something we describe and audit later into something we can govern before release and verify afterward.

---

**Status:** Literacy draft. This primer explains the construct; it does not itself establish conformance, certification, or a capability claim.