Five pathway engines. Five determinism mechanisms. One record discipline.
FERZ sits at the point where AI outputs, decisions, and actions become operationally consequential. It does not replace the AI agent, the model, the application, the IAM layer, or the system of record. The FERZ architecture comprises five pathway engines, designed around a common interoperability model and record discipline. Each pathway specifies the evidence associated with the decisions or outputs it governs.
Where FERZ sits
FERZ sits at the point where AI outputs, decisions, and actions become operationally consequential. For an AI agent proposing actions to a system of record, that point is the action boundary. In the FERZ architecture, a proposed action passes through the runtime authorization boundary before it can take effect: allowed actions proceed and blocked actions do not. Every decision produces an integrity-checked record.
The boundary is in path at the action boundary, not a monitor watching alongside the system: in the FERZ architecture, a proposed action cannot take effect without passing through it. Enforce mode conditions release on the verdict. Observe mode records and evaluates without blocking. Every record identifies its configured enforcement mode. Whether that mode controls external execution depends on the deployed release path.
Implementation status. The reviewed implementation provides content evaluation, integrity-checked records, and in-process verification, with enforcement mode recorded. Remaining development includes action release, keyed integrity, signing, and independent reconstruction from an exported evidence package. Scope and sequencing are subject to financing and prioritization. Pilots are scoped accordingly.
The five pathway engines
FERZ owns five patent-pending architectural pathways to deterministic governance. Each pathway engine implements one of them. The engines are independently licensable; the panels below give an applied overview of each, with a link to the deep page for the architectural detail.
LASO(f)
Semantic Determinism, for meaning and coherence
What it is designed to produce: Verdict (ALLOW, DENY, or ABSTAIN) and an authorization artifact for every AI language or action output evaluated against codified semantic standards.
Operational use case: AI deployments where outputs must be checked for compliance against codified language and meaning standards before they leave the system.
Status: Available for pilot and implementation discussions.
Constraint Determinism, for bounded executable constraints
What it is designed to produce: Verdict (ALLOW, DENY, or ABSTAIN) and an authorization artifact for every AI output evaluated against the active constraint set.
Operational use case: Regulated environments where AI outputs must conform to codified compliance constraints before they leave the system.
Status: Available for pilot and implementation discussions.
Adaptive Determinism, for deterministic bounded adaptation
What it is designed to produce: Adapted AI output paired with an explainable rationale, and a record of the trajectory state, modifiers applied, and ceiling in force.
Operational use case: Coaching, education, workforce, and wellbeing contexts where adaptation must respond to operational context without crossing codified ceilings.
Causal Determinism, for deterministic causal modeling
What it is designed to produce: Causal structure with an explainable causal pathway, and a causal record traceable from input through engine selection to causal output.
Operational use case: Multi-tier and cross-domain analysis where causal claims must be deterministic and independently re-derivable.
Status: Available for pilot and implementation discussions.
Consensus Determinism, for distributed authority over governing rules, decision records, and halt operations
What it is designed to produce: Consensus verdict and a record of the distributed authority decision, verifiable against the consensus protocol.
Operational use case: Cross-jurisdiction and multi-authority deployments where deterministic oversight is achieved across distributed validators rather than concentrated in a single authority.
Status: Architecture specified; implementation roadmap in development.
The verdict flow described here is the pattern used by the authorization engines: LASO(f), DELIA, and Constitutional Blockchain. Each proposed action is evaluated against policy and resolves to one of three verdicts. ALLOW permits execution. DENY blocks it. ABSTAIN blocks execution and holds it pending an authorized human override. There is no separate ESCALATE verdict, and there is no default that lets an unresolved action through.
In enforce mode, ABSTAIN is fail-closed: execution is held, not passed through, until a human authorizes the override. The override is itself an authorized action and produces its own artifact.
CausaCore and the FERZ Behavioral Engine do not produce verdicts; they produce other artifact types (causal structure with an explainable pathway; adapted output with an explainable rationale) on the same record discipline. When composed with an authorization engine, the authorization engine treats their output as the modeled domain or operational context that its verdict is decided over.
What FERZ produces: the authorization artifact
Every engine produces an evidence artifact for every decision or output it generates. The artifact records what was decided or produced, the inputs the decision was made on, the enforcement mode in force, and an integrity check over those contents. The Five Tests Standard requires artifacts of this class to be tamper-evident and independently replayable; the current record is integrity-checked, and keyed integrity followed by signing is on the roadmap. The fields common to every engine are shown below; engine-specific contents fill the result payload (the verdict for authorization engines, the causal pathway for CausaCore, the adapted output and modifiers applied for the FERZ Behavioral Engine, the consensus result for Constitutional Blockchain).
Specified authorization-artifact fields. The artifact shown is the authorization-engine variant; the same field discipline applies across all engines. The result field carries the engine-specific output (verdict for LASO(f), DELIA, and Constitutional Blockchain; causal pathway for CausaCore; adapted output for the FERZ Behavioral Engine).
A worked example: an AI agent in a loan workflow
Consider an AI assistant operating in a loan-origination workflow. It can propose consequential actions: approving an application, declining one, or issuing a decision notice. Lending decisions are subject to fair-lending and adverse-action requirements that demand each decision be documented and examinable after the fact. Here is how FERZ handles three proposed actions.
The example illustrates the intended behavior of the authorization boundary.
ALLOWThe agent proposes a decision within policy and authority.
The proposed action is consistent with the encoded lending policy and falls within the agent's authority. FERZ returns ALLOW, permitting release through the governed execution path. An artifact records the verdict, the policy version applied, and the inputs the decision was made on.
Composition note. The FERZ Behavioral Engine can adapt the approval communication to the applicant's operational context within configured intensity ceilings; CausaCore can produce an explanation of the causal factors behind the approval, useful for portfolio-level analysis.
DENYThe agent proposes a decision the policy prohibits.
The proposed action conflicts with the encoded policy, for example by resting on a factor the policy does not permit, or by exceeding the agent's authority. FERZ returns DENY and the action is not released. The artifact records the denial and the policy basis for it. DENY blocks the proposed action; it does not itself mean that the credit application is declined. Any subsequent credit decision and related communication must follow the applicable governed workflow.
Composition note. CausaCore can produce the deterministic causal pathway documenting the factors that drove the denial, useful for review of the policy basis and for portfolio-level analysis. Meeting any statutory notification requirements remains the customer's obligation under its own governed workflow.
ABSTAINThe agent proposes a decision the policy cannot resolve.
The proposed action falls outside what the policy can resolve on its own. FERZ returns ABSTAIN and holds execution. A human loan officer reviews and, if appropriate, authorizes an override. The override is itself an authorized action and produces its own artifact, so the human decision is recorded with the same evidentiary standing as an automated one.
Composition note. The FERZ Behavioral Engine can adapt the communication during the human-review hand-off to the applicant's context; CausaCore can produce the causal pathway that informed the policy boundary, helping the human reviewer evaluate the override question deterministically rather than from intuition alone.
Replaying the decision
Because each artifact carries the policy version, the canonicalized action, the governed state, and the evaluator version, the decision can be reconstructed. The architecture specifies that the artifact can be replayed to confirm the verdict from its recorded inputs, without access to the running system.
For the loan workflow, this is the difference between telling an examiner that a decision was authorized and showing it. The architecture is designed so that, months later, an auditor can take the artifact for a given decision and verify that it was authorized under the policy in force at the time, without the original system running or trusted.
For deterministic decisions, replay reproduces the verdict exactly; for inference-dependent decisions, replay re-runs the acceptance gates and the verdict must match, with instability resolved to ABSTAIN.
Frequently asked questions
Where does FERZ sit in my stack?
In the FERZ architecture, the boundary sits in front of your AI system's action layer, at the point where a proposed action would cross from internal reasoning to external effect. In enforce mode, each proposed action passes through the authorization boundary before it can execute. In observe mode, FERZ evaluates and records without blocking execution. Every record identifies its configured enforcement mode.
What is in an authorization artifact?
Each artifact records the verdict, the policy version applied, the canonicalized action specification, the governed state, the evaluator version, and the enforcement mode, and it carries an integrity check over those contents. These inputs are specified as sufficient to reconstruct and re-check the decision.
How does an auditor verify a past decision?
Because the artifact carries the policy version, the canonicalized action, the governed state, and the evaluator version, the architecture specifies that an auditor can replay or re-check the decision from the recorded inputs without access to the running system. For deterministic decisions, replay reproduces the verdict exactly; for inference-dependent decisions, replay re-runs the acceptance gates, with instability resolved to ABSTAIN.
What are the possible verdicts?
ALLOW, DENY, and ABSTAIN. ALLOW permits execution. DENY blocks it. ABSTAIN blocks execution pending authorized human override. There is no separate ESCALATE verdict. The verdict space applies to the authorization engines (LASO(f), DELIA, Constitutional Blockchain). The pathway engines that do not produce verdicts (CausaCore, FERZ Behavioral Engine) produce other artifact types on the same record discipline.
Which engine do I need?
It depends on the architectural property you need to assure. LASO(f) for semantic meaning and coherence in AI language and action outputs. DELIA for bounded executable constraints (AI outputs that must conform to codified policy before leaving the system). FERZ Behavioral Engine for deterministic bounded adaptation (AI outputs that must adapt to operational context within mathematically governed ceilings). CausaCore for deterministic causal modeling across multi-tier and cross-domain systems. Constitutional Blockchain for distributed authority over governing rules, decision records, and halt operations across multiple validators. The five panels above and the engine deep pages describe each in more detail.
Can I license one engine or compose multiple?
The engines are offered for individual licensing, with implementation scope defined for the engagement. The intended architecture supports composition through a shared record discipline. A deployment can begin with one pathway and add others as its requirements develop.
How do engines share an audit trail when composed?
The architecture specifies a common artifact format and record discipline across engines. When multiple engines operate on the same workflow, their records are specified to link through the common fields (canonicalized input, policy or parameter version, evaluator version), so that the composed trail can be examined as one audit record spanning the engines that took part.