Five pathway engines. Five determinism mechanisms. One signed-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. The deployed engines produce signed evidence of the decisions or outputs they govern, and all five share a common interoperability model and signed-record discipline.
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: before the proposed action can take effect, it passes through the FERZ authorization boundary. Allowed actions proceed. Blocked actions do not. Every decision produces an artifact.
FERZ is in path at the action boundary. It is not a monitor watching alongside the system; a proposed action cannot take effect without passing through it. This is enforce mode; FERZ can also deploy in observe mode, out of path, where it records and evaluates but does not block.
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 produces: Verdict (ALLOW, DENY, or ABSTAIN) and a signed 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 produces: Verdict (ALLOW, DENY, or ABSTAIN) and a signed 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 produces: Adapted AI output paired with an explainable rationale, and a signed 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 produces: Causal structure with an explainable causal pathway, and a signed 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 produces: Consensus verdict and a signed 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 signed-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: signed evidence
Every engine produces a signed evidence artifact for every decision or output it generates. The artifact records what was decided or produced, the inputs the decision was made on, and a signature over those contents, so the record is tamper-evident and replayable. 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).
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.
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 and the action executes. 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 does not execute. The artifact records the denial and the policy basis for it.
Composition note. When the denial requires adverse-action notification (a regulatory obligation for declined credit applications), CausaCore can produce the deterministic causal pathway documenting the factors that drove the denial. The signed causal record provides the documented causal basis for adverse-action notices; meeting the specific statutory requirements remains the customer's obligation.
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 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. 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. The verification does not require the original system to be running or to be 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?
FERZ 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 out of path without blocking execution.
What is in an authorization artifact?
Each artifact records the verdict, the policy version applied, the canonicalized action specification, the governed state, and the evaluator version, and it carries a signature over those contents. These inputs are 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, 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 signed-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?
Either. Each engine is independently licensable and produces signed evidence. Engines that compose share an interoperability model: their signed records combine into a unified audit trail without rework. Most deployments begin with one engine matched to a primary architectural risk and add others as composition becomes valuable.
How do engines share an audit trail when composed?
All engines produce signed evidence in a common artifact format with a shared signature discipline. When multiple engines operate on the same workflow, their records can be sequenced or linked through the common fields (canonicalized input, policy or parameter version, evaluator version), and the signatures make the trail tamper-evident across the composition. The result is a unified audit record spanning the engines that took part.