ERIL Semantic Core | NovaFuse Technologies

Canonical Specification | Registry Reference: ERIL-SC-001
Author: NovaFuse Technologies
Version: 0.1 (Draft — Normative)
Status: Draft v0.1 (Normative)
Conformance Level: Semantic Core
Classification: Public Reference Specification / Voluntary Standard
Companion Publications:
  ERI-LX-001 - Executable Proof Lexicon
  ERI-RA-001 - Reference Implementation Blueprint
  ERIL-STD-001 - Revocation Specification
  CS-WP-001 - Cyber-Safety: The Paradigm Shift
Audience: System architects, standards bodies, regulators, implementers

What This Is

Most programming languages tell machines how to do something.

ERIL tells machines when something is allowed to happen.

ERIL is a semantic execution language designed to enforce governance, safety, and compliance at runtime — before execution occurs — and to produce cryptographic evidence on every path, including refusal.

It does not replace application code. It conditions whether code is allowed to run.

Document Intent: This is not marketing copy. It is a semantic core: definitions, invariants, and authority rules that other ERIL profiles, bindings, and reference implementations can depend on.

1. Scope and Purpose

This document defines the semantic core of ERIL, the Executable Reference Implementation Language used to govern admissible execution at machine speed. ERIL is not a general-purpose programming language. It is the language component of a governance protocol that determines whether execution is permitted to cross defined Release Boundaries (RBs).

This document specifies:

Decision semantics
Authority boundaries
Determinism requirements
Evidence obligations
Non-bypassability invariants

Out of scope: syntax, serialization formats, cryptographic algorithms, and deployment topologies. Those are defined in companion specifications.

2. Normative Language

The keywords MUST, MUST NOT, SHALL, SHALL NOT, SHOULD, MAY are to be interpreted as described in RFC-style normative usage, consistent with ERI Formalization v1.1.

3. The Problem ERIL Solves

Governance today is mostly advisory. Policies live in PDFs. Controls are checked after the fact. Evidence is collected manually. Violations are discovered after damage occurs.

This creates an execution gap between:

"What the policy says" and "What actually ran."

ERIL exists to close that gap.

4. Architectural Model (Normative)

4.1 Two-Plane Architecture

All ERIL-conformant systems SHALL be describable using two planes:

Plane	Function
Payload Plane (PP)	Performs computation and side-effects
Governance Plane (GP)	Determines admissibility and release authorization

The Governance Plane SHALL be externalized from the Payload Plane and SHALL NOT perform payload execution.

4.2 Binding Points and Release Boundaries

A Binding Point is a system interception location where an action may be evaluated for admissibility. A Release Boundary (RB) is the point beyond which system state changes become externally visible or irreversible effects occur.

Normative Rule: All Release Boundary crossings MUST be mediated by ERIL. Any execution path that crosses an RB without ERIL mediation invalidates conformance.

5. ERIL Decision Semantics (Normative)

5.1 Decision Set

ERIL evaluation SHALL produce exactly one of the following outcomes:

Decision	Semantics
`ALLOW`	Execution MAY proceed to the Release Boundary.
`REFUSE`	Execution SHALL NOT proceed; no external effects occur.
`ABORT`	Immediate termination with non-release; treated as a successful governance outcome under uncertainty.

At runtime, every governed action follows one of two paths:

✓ Admissible → execution proceeds
✗ Not verifiable → execution is refused

In both cases, a cryptographically verifiable evidence artifact is produced. There is no monitoring mode. There is no best-effort fallback. No verification = no action.

5.2 Fail-Closed Requirement

ERIL SHALL be deny-by-default. If admissibility cannot be proven, the outcome MUST be REFUSE or ABORT.

6. Determinism and the Determinism Envelope

Given identical inputs, an ERIL evaluation MUST produce identical decisions and evidence artifacts. Every ERIL evaluation MUST declare a Determinism Envelope — the complete set of inputs treated as relevant for determinism claims. Undeclared nondeterminism SHALL result in ABORT.

7. Graded Inputs and Binary Decisions

Inputs MAY encode graded or continuous values including confidence scores, risk bands, and uncertainty metrics. All graded inputs MUST be resolved into a binary ERIL decision. Escalation paths MAY exist but SHALL NOT result in implicit ALLOW. Human intervention, if used, MUST trigger re-evaluation.

8. Evidence Semantics (Normative)

8.1 Mandatory Evidence Emission

Every ERIL evaluation MUST emit a durable evidence artifact, regardless of outcome.

8.2 Minimum Evidence Fields

Evidence artifacts SHALL minimally bind: ERIL artifact identifier, input hash, Determinism Envelope hash, decision, and decision timestamp or sequence number. Evidence SHALL be suitable for independent verification.

Every ERIL-governed decision produces an evidence artifact that is cryptographically signed, immutable, replayable independently, and does not require access to the live system. This allows auditors, regulators, and third parties to verify compliance without trusting logs, screenshots, or internal attestations.

9. Verification Actor Model (Normative)

Actor	Role
Issuer	Evaluates ERIL and issues decisions
Executor	Executes payload actions
Verifier	Independently validates decisions
Auditor	Reviews historical correctness

The Issuer and Executor SHALL be authority-separated. The Verifier SHALL NOT require trust in either Issuer or Executor.

10. Minimal Reference Flow (Normative)

An ERIL-conformant system MUST be able to demonstrate the following flow:

Intent submitted to Issuer
ERIL evaluation performed
Decision artifact emitted and recorded
Execution occurs only if decision = ALLOW
Verifier recomputes admissibility and validates RB crossing

Failure at any step invalidates conformance.

11. ERIL Semantic Primitives

ERIL defines five semantic primitives that create complete logical closure:

Primitive	Symbol	Meaning
`ENTITY`	—	What exists and is governed
`INVARIANT`	⊢	What must be true for execution to be considered
`GUARD`	?	What blocks execution if unverifiable
`EXECUTION`	→	What action is permitted
`EVIDENCE`	⇝	What proves the decision

Example: A Minimal ERIL Rule

rule RegulatedDataAccess {

  requires identity.verified
  requires purpose.bound
  requires authorization.valid

  on_violation refuse_execution
  emit evidence
}

If all conditions are verifiable → execution proceeds. If any condition cannot be verified → execution is refused. An evidence artifact is emitted in all cases. The refusal is the control. The artifact is the audit.

Example: Medical Risk Extractor

ENTITY: PatientRiskExtractor

  ⊢ coherence.psi >= 2847
  ? identity.role in ["licensed_clinician", "ems_paramedic"]
  -> extract_risk_signals(transcript)
  ~> signed_artifact + refusal_log

Example: AI Factory Job Start

ENTITY: AIFactoryJobStart

  ? ida.affirm() AND da.affirm() AND oa.affirm()
  ? quorum(3) == true
  -> submit_to_scheduler()
  ~> fcc(rb-1, authority_set, quorum, commit_hash)

12. The Mental Model

If traditional code answers: "What should the system do?"

ERIL answers: "Is this execution allowed to happen at all?"

You can think of ERIL as:

Types, but for governance
Unit tests, but enforced at runtime
Contracts, but executable
Safety interlocks, but for software

13. What ERIL Is Not

ERIL is not: a general-purpose programming language, a policy DSL that "suggests" behavior, a logging or monitoring system, a dashboard or reporting tool, or a replacement for your application stack.

ERIL does not tell systems how to compute. It tells systems whether computation is allowed to exist.

14. Relationship to ERI and CERI

ERIL is the semantic language used to express governance rules. The Executable Reference Implementation (ERI) is the runnable artifact that enforces a rule, refuses execution when the rule cannot be satisfied, and produces verifiable evidence. The CERI (Contained ERI) is the packaged runtime form that carries the ERI, the ERIL boundary, and the evidence pattern together so the claim can execute in a controlled environment.

General-purpose languages SHALL NOT authorize Release Boundary crossings. This separation is fundamental and non-negotiable.

15. Conformance Claims

An implementation SHALL NOT claim ERIL conformance unless all MUST and SHALL requirements in this document are satisfied. Partial implementations MAY claim ERIL-inspired, but not ERIL-conformant.

16. Non-Goals (Important)

This specification does not attempt to: define a full platform, provide industry-specific controls, replace existing GRC tooling, or prescribe organizational processes.

Its purpose is singular: to demonstrate that governance can be enforced at runtime — and proven.

17. Security and Governance Considerations

ERIL's primary security property is non-bypassable admissibility. Its primary governance property is independently verifiable refusal. Together, these enable runtime governance at AI speed, closing the gap between what policy says and what actually ran.

Why This Matters: If compliance, safety, or governance is critical enough to document, it is critical enough to enforce before execution. If enforcement happens only after execution, then compliance is retrospective — not real. ERIL makes governance executable.

ERIL-SC-001 — ERIL Semantic Core v0.1 — Draft Normative — NovaFuse Technologies — 2026