License the Enforcement Layer

Governance is the market category; authorization is the enforcement mechanism.

FERZ licenses runtime authorization infrastructure for AI systems in regulated industries: five independently licensable pathway engines, grounded in published doctrine, a published standard, and filed patent applications. Partners deliver, integrate, and embed the enforcement capability.
Three
Verdicts: ALLOW, DENY, ABSTAIN. ABSTAIN blocks execution pending authorized human override.
Five
Tests in the Five Tests Standard (5TS): Stop, Ownership, Replay, Escalation, Provenance.
Fail-closed
If a conforming output cannot be established, execution is blocked. Non-conforming output is never released.
Tamper-evident
Every verdict is recorded as a tamper-evident authorization artifact.

What FERZ Licenses

FERZ is a product company. Its products are infrastructure software: containerized, deployable into the customer's environment or hosted by FERZ. The FERZ architecture comprises five pathway engines, each implementing one patent-pending architectural pathway to deterministic governance. Each engine is independently licensable; engines that compose share an interoperability model, so their signed records combine into a unified audit trail. Licensing scope, structure, and terms are defined per engagement.

Semantic Determinism

Governs meaning and coherence: evaluates AI language and action outputs against codified semantic standards, producing a verdict and authorization artifact for every output evaluated.

Constraint Determinism

Governs bounded executable constraints: evaluates AI outputs against the active constraint set before they leave the system, producing a verdict and authorization artifact for every output evaluated.

Adaptive Determinism

Governs deterministic bounded adaptation: produces adapted AI output paired with an explainable rationale, and a record of the trajectory state, modifiers applied, and ceiling in force.

Causal Determinism

Governs deterministic causal modeling: produces causal structure with an explainable causal pathway, traceable from input through engine selection to causal output.

Consensus Determinism

Governs distributed authority over governing rules, decision records, and halt operations, with a consensus verdict recorded and verifiable against the consensus protocol.

The full architecture overview is at How FERZ Works.

The authorization engines (LASO(f), DELIA, and Constitutional Blockchain) resolve each governed action to a verdict. CausaCore and the FERZ Behavioral Engine do not produce verdicts; they produce other artifact types on the same record discipline, and when composed with an authorization engine, their output becomes the modeled domain or operational context the verdict is decided over. Every engine's artifact is designed to carry a signature over its recorded contents, making the record tamper-evident and supporting independent reconstruction of the decision or output it records. A FERZ authorization artifact is designed to implement the proof-carrying decision object required by 5TS.

Enforcement, Not Monitoring

Most AI governance tooling observes. It logs what a system did, scores what a system produced, and reports what a system got wrong. Observation is necessary. It is not authorization.

Monitoring describes what happened. Runtime authorization produces evidence of what was permitted before occurrence. That distinction is structural, not a maturity gap: no volume of after-the-fact observation can convert a record of events into evidence that an action was authorized when it executed.

FERZ sits at the authorization boundary: the point where an AI output becomes an effect-bearing action. At that boundary, the architecture is designed to produce a deterministic verdict before execution, block anything not affirmatively allowed, and record the authorization verdict in a form designed to support independent reconstruction.

For partners, this is the differentiation that matters in regulated procurement. Observability overlays compete on dashboards. An enforcement layer competes on evidence.

Built on a Published Standard

FERZ publishes its doctrine, standards, and research corpus openly (Zenodo, SSRN, GitHub). The Five Tests Standard (5TS) defines five normative tests for AI governance enforcement:

  • Stop. Can the system halt an action before it executes?
  • Ownership. Is there an accountable authority for every rule in force?
  • Replay. Can a verdict be independently reconstructed after the fact?
  • Escalation. Does blocked execution route to authorized human override rather than silent failure?
  • Provenance. Is the origin of the inputs grounding the verdict established? Provenance is origin, not truth.

Machine-checkable conformance vectors are published for the four predecessor tests; Provenance conformance is currently specified at the definitional level.

Partners build on the standard, reference it in proposals, and deliver against it. The standard is published; the enforcement infrastructure that implements it is what FERZ licenses.

Partnership Tracks

FERZ products separate code from configuration. Governance rules are data, authored through a defined codification process, not custom software. The architecture is designed for partner delivery: system integrators, consultancies, and platform vendors can be trained to configure and deliver FERZ products without touching the product codebase.

FERZ structures each partnership to fit the opportunity. The tracks below describe common engagement patterns, not fixed programs.

Certified Implementer
For system integrators and consultancies. Certified Implementers will be trained to deliver rule elicitation, policy codification, and deployment configuration for FERZ products in client environments as FERZ's certification program is formalized. FERZ is developing a certification program covering architecture fundamentals, rule engineering, and deployment operations.
What partners get: delivery revenue on configuration engagements, a differentiated enforcement capability in regulated pursuits, and a defined methodology to deliver against.
Technology Partner
For software vendors and infrastructure providers whose products sit adjacent to the authorization boundary. Technology Partners integrate their products with FERZ interfaces so that authorization verdicts and authorization artifacts flow into the systems their customers already operate.
What partners get: integration review, joint solution documentation where appropriate, and a governance answer for regulated customers whose systems sit adjacent to the authorization boundary.
OEM and Embedded
For platform vendors embedding enforcement as a native capability within their own offerings. FERZ products are designed to be called from a platform's orchestration layer, with configuration surfaces that can be white-labeled and authorization artifacts that feed the platform's compliance tooling.
What partners get: an enforcement layer without building one, and evidence-grade governance output their customers can present to regulators and auditors.

Intellectual Property Position

FERZ's five architectural pathways to deterministic governance are each the subject of filed patent applications, including three PCT applications, with prosecution managed by outside IP counsel. Licensing is intended to provide partners with a defined permission path to use FERZ-controlled methods within the licensed scope, subject to negotiated commercial terms.

FERZ makes no representation about the outcome of pending applications. The IP position is disclosed accurately: filed, pending, and published where the corpus is published.

Deployment Posture

Governance executes where the customer's security posture requires. FERZ products are designed to support deployment across cloud VPC, on-premises, and air-gapped environments, with no required external network dependency in customer-deployed configurations. Customer-specific rules are configuration data, not product forks.

Two deployment models are contemplated: customer-deployed, where FERZ containers run inside the customer's infrastructure and can be configured so FERZ does not receive customer data; and FERZ-hosted, for customers whose data-residency and security requirements permit hosted operation. The deployment model is a packaging decision, not a change to the authorization model.

How Engagement Works

1
Qualification. Mutual assessment of market position, target verticals, and integration surface. FERZ partnerships concentrate on healthcare, financial services, and government and defense.
2
Technical Evaluation. Interface-level technical review under NDA: authorization boundary placement, artifact consumption, alignment with 5TS requirements, machine-checkable conformance where published, and deployment model fit.
3
Structuring. Commercial terms, scope definition, and delivery or integration plan, matched to the engagement pattern.

Start the Conversation

If your customers operate in regulated markets and your proposals need enforcement evidence rather than monitoring dashboards, the conversation is worth having.

Contact: info@ferz.ai

Partnership descriptions on this page reflect FERZ's current architecture, filed intellectual property, and published standards. Capabilities described in design terms are design-intent statements, not certifications or deployment claims. FERZ does not publish customer names, certifications, or deployment claims it cannot substantiate.
Cite this page
FERZ, Inc. (2026). AI Governance Licensing & Partnerships. https://ferz.ai/licensing-and-partnerships