Operationalized Cyber-Safety: Runtime Admissibility Architecture

Technical Reference | Registry Reference: CS-TR-001
Author: NovaFuse Technologies
Date: July 2026
Version: 1.0.0
Classification: Public / Technical Reference
Companion Publication: CS-WP-001 - Cyber-Safety: The Paradigm Shift

Abstract

Cyber-Safety is the discipline created by bringing Governance, Risk, and Compliance (GRC), Information Technology (IT), and Cybersecurity together at the point where a digital effect attempts to become a committed outcome.

This technical reference defines how that discipline is operationalized in software.

Operationalized Cyber-Safety is a bounded runtime admissibility architecture that intercepts governed digital state transitions before commit, evaluates declared identity, context, authority, data, network, AI, policy, risk, integrity, economic, and evidence conditions, then resolves the attempt as commit or refusal with native runtime evidence.

The central claim is intentionally bounded:

Inside a NovaFuse-governed execution boundary, non-admissible transitions cannot become valid committed outcomes.

This document defines the execution boundary, formal invariants, reference runtime flow, evidence model, and relationships among ERI, ERIL, CERI, IDNA, G-Tx, NovaPay, NovaVault-X, and supporting enforcement substrates.

1. Relationship to the Cyber-Safety Doctrine

CS-WP-001 - Cyber-Safety: The Paradigm Shift defines the category-level transformation:

Cyber-Safety = GRC + IT + Cybersecurity

The white paper explains why event-driven correction is insufficient for consequential digital actions and why selected requirements from all three domains must be capable of becoming runtime conditions of execution.

This document begins one layer lower. It specifies the architecture required to place admissibility before commit inside a declared technical boundary.

Cyber-Safety defines the discipline. Operationalized Cyber-Safety defines its bounded runtime implementation.

2. Operational Definition

Operationalized Cyber-Safety is a bounded runtime admissibility architecture that:

1. identifies an attempted effect before state commitment;
2. establishes the governed execution boundary;
3. assembles the context required by the declared policy;
4. evaluates admissibility conditions;
5. resolves the attempt as commit or refusal;
6. binds the resolution to native runtime evidence.

Five boundaries are essential:

• Bounded: The claim applies to a declared governed execution path.
• Pre-commit: Evaluation occurs before the transition becomes a valid committed outcome.
• Admissibility-based: Access alone is insufficient; the attempted effect must satisfy the applicable conditions.
• Commit/refuse: Both outcomes are governed and explicit.
• Evidence-native: The resolution path emits evidence rather than relying only on retrospective reconstruction.

3. Control Object: The Attempted Effect

The control object is the attempted effect, not the actor's unobservable internal intention.

An attempted effect may include:

• an API call;
• an AI agent tool invocation;
• a data access or transfer request;
• a payment or settlement instruction;
• an infrastructure mutation;
• a workflow state change;
• a network operation;
• a software evaluation run;
• or another action capable of producing a consequential digital outcome.

Operationalized Cyber-Safety governs the point at which that attempt seeks to cross from proposed motion into committed state.

4. Four-Layer Runtime Model

4.1 Ontology: What Exists

The runtime recognizes actors, attempted effects, governed boundaries, contextual claims, admissibility rules, decisions, committed or refused outcomes, and evidence artifacts.

4.2 Constraint Model: What Is Allowed

The implementation evaluates the conditions declared for the governed action. Conditions may concern identity, authority, data, network, AI, policy, risk, integrity, economic proof, or evidence obligations.

The constraint set is explicit and scoped. A runtime does not claim to evaluate conditions that are absent from its declared policy or unavailable within its boundary.

4.3 Execution Rule: What Happens

Only admissible transitions commit. If required conditions are unsatisfied, unavailable, invalid, expired, or contradictory under the declared rule set, the transition is refused before commit.

Refusal is a first-class outcome, not an implementation failure.

4.4 Evidence Model: What Is Recorded

Every governed resolution emits evidence describing the attempt, relevant context, evaluated rule set, decision, outcome, boundary, and time or sequence information required by the implementation.

Evidence supports verification of the governed decision. It does not automatically prove claims outside the declared boundary.

5. Formal Runtime Invariants

An implementation of Operationalized Cyber-Safety is evaluated against invariants rather than promotional descriptions.

Invariant I: Non-Admissible Transitions Do Not Commit

Inside the governed execution boundary, an attempted transition that does not satisfy required admissibility conditions cannot become a valid committed state change.

Invariant II: Commits Are Evidence-Bound

Every permitted transition emits evidence sufficient to identify the attempted effect, evaluated context, applicable rule or policy reference, decision, and committed outcome within the implementation's declared evidence model.

Invariant III: Refusals Are Evidence-Bound

Every refused transition emits evidence sufficient to show that the attempt reached the governed boundary, was evaluated, and did not commit.

Invariant IV: Admissibility Is Evaluated at Attempt Time

The applicable governance is evaluated when the effect seeks to become a committed transition, not solely after downstream effects have materialized.

Invariant V: Boundary and Policy Are Identifiable

The evidence model identifies which governed boundary and policy version produced the decision. A decision without identifiable scope cannot support a precise technical claim.

Invariant VI: No Silent Governed Outcome

An attempt accepted into the governed decision path resolves as commit, refusal, or an explicitly evidenced bounded failure state. It does not disappear without a resolution artifact.

6. Reference Runtime Flow

Attempted Effect
  -> Boundary Intercept
  -> Context Assembly
       Identity
       Authority
       Data
       Network
       AI
       Policy / Compliance
       Risk
       Integrity
       Economic Proof, when required
       Evidence Requirements
  -> Admissibility Evaluation
  -> Commit | Refuse | Evidenced Bounded Failure
  -> Evidence Emission

The flow is logical rather than prescriptive. Implementations may distribute these functions across services, policy engines, confidential-compute boundaries, gateways, local agents, sidecars, control planes, or embedded enforcement points.

The invariant is the ordering: required admissibility evaluation precedes valid state commitment inside the governed path.

7. IDNA: The Four-Domain Interaction Surface

IDNA organizes four major domains through which digital actions obtain meaning and consequence:

• Identity: Who or what is attempting the effect, under which credentials, delegation, role, or capability.
• Data: Which information is involved, how it is classified, and which handling constraints apply.
• Network: Where the action originates, travels, terminates, or propagates and which environmental conditions apply.
• AI: Whether autonomous or semi-autonomous reasoning initiates, recommends, transforms, or executes the action and under what authority.

IDNA is not itself the complete admissibility decision. It provides a structured interaction surface whose claims can participate in that decision.

8. ERI, ERIL, and CERI

8.1 ERI: Executable Reference Implementation

ERI makes a technical claim runnable, inspectable, testable, and evidence-bearing inside a declared boundary. It provides executable proof that an architecture can exhibit specified behavior under stated assumptions.

ERI is not a claim that one reference implementation proves every production environment. It is a controlled verification surface.

8.2 ERIL: Executable Reference Implementation Language

ERIL expresses admissibility rules, boundaries, required context, decision paths, evidence obligations, and revocation behavior in a form that can be interpreted or executed by a conforming runtime.

8.3 CERI: Contained Executable Reference Implementation

CERI packages the claim, boundary, rules, implementation, and evidence pattern into a controlled executable form. The purpose is to preserve the relationship between what is claimed, what runs, under which conditions, and what evidence is produced.

9. G-Tx: Governed Transaction

G-Tx is the observable governed-transition primitive.

A G-Tx represents an attempted motion that:

1. enters a declared governed boundary;
2. receives the required context;
3. is evaluated for admissibility;
4. resolves as commit, refusal, or evidenced bounded failure;
5. produces a corresponding evidence artifact.

G-Tx is not the definition of Cyber-Safety. Cyber-Safety is the discipline; G-Tx is an observable protocol and measurement surface through which governed motion can be described and verified.

10. Economic Admissibility and NovaPay

Some actions require economic proof as part of their admissibility conditions. Examples may include payment, settlement status, stake, quota, gas, contractual entitlement, or another declared economic prerequisite.

The generalized rule is:

No required economic proof
  -> no economic admissibility
  -> no valid governed commit

NovaPay supplies this constraint dimension where applicable. It is not merely a billing mechanism; it can make required economic proof consequential before capability issuance or execution.

11. Evidence-Bound Evaluation and NovaVault-X

NovaVault-X applies the Operationalized Cyber-Safety pattern to protected software evaluation.

An evaluation artifact runs inside a declared proof boundary. The evaluator receives evidence about the governed run without requiring possession of the protected source as a precondition of evaluation.

NovaVault-X governs the declared evaluation event. It does not claim to govern every downstream use of the result, every external environment, or every action outside the proof boundary.

12. Enforcement Substrates

Operationalized Cyber-Safety is substrate-independent at the doctrine level. Implementations may use combinations of:

• policy decision and enforcement points;
• confidential computing and hardware attestation;
• isolated execution;
• signed receipts and append-only evidence;
• capability-bound identity;
• formal verification artifacts;
• gateways, sidecars, local agents, or embedded libraries;
• deterministic control planes;
• and environment-specific runtime controls.

Hardware-backed enforcement may strengthen particular execution and evidence properties. It does not justify a blanket claim that all external systems or downstream behavior are safe.

13. Failure and Refusal Semantics

Operationalized Cyber-Safety distinguishes refusal from system failure.

• Refusal: The runtime evaluated the attempt and determined that required admissibility conditions were not satisfied.
• Bounded failure: The runtime could not complete the decision because a declared dependency, context source, integrity check, or enforcement surface failed.
• Commit: The runtime evaluated the attempt as admissible and allowed the governed transition to become a valid committed outcome.

The default behavior for missing required proof is refusal or explicitly evidenced bounded failure, according to the declared policy. Missing proof must not silently become permission.

14. Validation and Evidence Scope

Evidence must be interpreted according to what produced it.

• A Proof Run validates a declared scenario, workload, boundary, and evidence path.
• An ERI validates a construct under stated assumptions.
• A technical reference defines architecture, invariants, vocabulary, and claim boundaries.
• A production deployment requires environment-specific integration review, threat modeling, operational controls, policy ownership, monitoring, and legal or compliance review where applicable.

No single artifact should be generalized beyond its declared scope.

15. Conformance Questions

An evaluator assessing an Operationalized Cyber-Safety implementation should be able to ask:

1. What attempted effects are inside the governed boundary?
2. Where is the pre-commit intercept?
3. Which admissibility conditions apply?
4. Which sources provide context and authority?
5. What occurs when required proof is missing or stale?
6. Can a non-admissible attempt reach valid commit through another path?
7. What evidence is emitted for commit, refusal, and bounded failure?
8. Are the boundary, policy version, and decision identifiable in the evidence?
9. Which claims are demonstrated by tests or Proof Runs?
10. Which systems and downstream effects remain outside the boundary?

These questions turn the architecture into an evaluable technical claim.

16. Claim Boundaries

Operationalized Cyber-Safety does not claim that:

• all attacks are eliminated;
• all compliance obligations are automatically satisfied;
• policy is always correct;
• upstream context sources are infallible;
• downstream systems outside the boundary are controlled;
• or one implementation replaces GRC, IT operations, cybersecurity, audit, legal judgment, or human accountability.

It claims that a declared execution path can evaluate specified conditions before commit, refuse non-admissible transitions within that path, and emit evidence describing the resolution.

17. Conclusion

Operationalized Cyber-Safety makes the Cyber-Safety discipline technically actionable.

Attempted effect
  -> declared boundary
  -> assembled context
  -> admissibility decision
  -> commit or refusal
  -> native evidence

The architecture changes the temporal relationship between execution and governance. Selected requirements from GRC, IT, and Cybersecurity become conditions that must be resolved before a governed transition can commit.

Cyber-Safety defines the paradigm. Operationalized Cyber-Safety defines the bounded runtime architecture through which the paradigm can be implemented, tested, and evidenced.

Status: CANONICAL TECHNICAL REFERENCE - INITIAL PUBLICATION
Classification: Operationalized Cyber-Safety Runtime Architecture
Version: 1.0.0