The hospital network was running twenty-three sites, four clinical AI vendors, and eleven access control lists. Every new model meant another integration meeting. Every regulatory review meant another spreadsheet. The Zone Builder replaced that with one regime, evaluated against every act.

The Operational Problem

The hospital group's clinical AI stack was not unusual for an institution of its size. Diagnostic models ran in radiology, oncology triage ran in pathology, scheduling inference ran in operations, and an LLM-assisted documentation tool ran in primary care. Each model was sourced from a different vendor, hosted on different infrastructure, and governed by a separate access policy — drafted by a different team, on a different schedule.

This produced predictable symptoms:

  • → Cross-departmental data acted as if it were one dataset, but no single rule applied to all of it. A radiologist's inference access did not transfer to oncology; an oncology triage rule did not cover scheduling; nothing linked them.
  • → AI workflow oversight fell back to spreadsheets. Every review board meeting opened with a slide deck re-deriving what was deployed, where, and under whose authority. Drift was not the exception; it was the steady state.
  • → Jurisdiction-bound data residency was enforced per site by per-team runbooks. One site might run a model in-country; another would route through a cloud that had not been approved by the data protection officer.
  • → Audit trail for clinical AI was a separate concern from access control — and from financial settlement. When something went wrong, the institution opened three investigations: one for data, one for the model, one for who paid whom.
  • → Multi-stakeholder compliance conversations repeated every quarter. Each vendor contract, each IRB review, each internal audit committee re-litigated the same authority graph.

This is the shape of the problem that Zone Builders are for: not one workflow, not one site, but a regime that spans institutional actors, jurisdictional boundaries, and clinical review gates.

Where the Zone/Regime Model Fits

An Axone Zone is a normative regime — a bounded set of facts and rules, written in Prolog, that decides which acts become opposable inside it. An Axone Regime is the rule system itself: actor roles, evidence requirements, payouts, prohibitions, review gates, and conflict resolution.

For a healthcare operator, that distinction maps cleanly onto existing institutional vocabulary:

  • → A single Zone encompassing multi-site clinical AI workflows. Every act — every model invocation, every data access, every settlement — is evaluated against the same regime. Sites and vendors don't drift; they are members of one regime.
  • → Operator / data-controller / processor roles declared once. GDPR's three-party structure becomes three predicates in the regime. Vendors cannot impersonate the operator; sites cannot impersonate the controller.
  • → Per-jurisdiction inference routing encoded as a rule, not a runbook. A model call from site_a routed to a hosting tower inside the wrong jurisdiction simply does not become opposable — it's an unrecorded act under the regime.
  • → RBAC for clinicians expressed as role predicates. A radiologist can call a diagnostic model; a scheduler cannot — not because an ACL says so, but because the regime says so. The same rule travels with the act.
  • → IRB-style review gates as opposability preconditions. An act tied to a new model is qualified only if a review-board signing act precedes it. Inference cannot outrun approval.
  • → Audit-grade act logging on Layer 1. Every committed act is a fact recorded on-chain — timestamped, attributable to the role that qualified it, and reviewable without joining a vendor's audit portal.

The Zone Builder is the layer that turns this into something a clinical engineering team can ship: a typed artifact, versioned, parameterizable, repeatable.

A Prolog Regime Walkthrough

Below is an anonymized slice of the regime the hospital group runs. Roles are not placeholders for real institutions — they are anonymous identifiers, deliberately shaped to show how the abstract types fit together. No site data, no patient data, no vendor metadata.

prolog · Healthcare Zone Regime — Cross-Site Clinical AI 
% ============================================================
% HEALTHCARE ZONE REGIME — CROSS-SITE CLINICAL AI (ANONYMIZED)
% ============================================================

% ---------- ROLES (operator / controller / processor per site) ----------

actor(site_a,           controller).
actor(site_b,           processor).
actor(site_c,           processor).
actor(clinical_leadership, operator).
actor(review_board,     arbiter).

% ---------- RBAC: which role can call which model ----------

role_eligible(controller,  diagnostic_inference).
role_eligible(operator,     triage_routing).
role_eligible(processor,   scheduling_inference).
role_blocked(processor,    diagnostic_inference).

% ---------- Jurisdictions: data residency per site ----------

jurisdiction_of(site_a,  region_alpha).
jurisdiction_of(site_b,  region_beta).
jurisdiction_of(site_c,  region_alpha).

jurisdiction_approved(region_alpha, tower_eu_1).
jurisdiction_approved(region_beta,  tower_eu_2).

% ---------- Quotas: bound each site's inference volume ----------

quota(site_a, diagnostic_inference, 40).
quota(site_b, scheduling_inference, 120).
quota(site_c, scheduling_inference, 80).

% ---------- Quorum for review-board ratification ----------

quorum_required(new_model_signoff, 3).

% ============================================================
% ---------- RULES — what makes an act opposable ----------
% ============================================================

% Rule 1: a clinical inference is qualified if the actor is eligible,
%         jurisdiction-allowed, and under quota.

qualified(Site, infer(Model), Tower) :-
    actor(Site, Role),
    role_eligible(Role, Model),
    jurisdiction_of(Site, Reg),
    jurisdiction_approved(Reg, Tower),
    quota(Site, Model, Q),
    Q > 0.

% Rule 2: a new model becomes callable only after a ratified review.

model_cleared(Model) :-
    act_committed(_, ratify(Model), _),
    ratification_count(new_model_signoff, N),
    N >= 3.

% Rule 3: opposability — every qualified infer call is opposable
%         (contestable, auditable, with effect).

opposable(infer(Model), Site, Tower) :-
    qualified(Site, infer(Model), Tower),
    model_cleared(Model).

% ---------- EFFECT — what an opposable act produces ----------

effect(infer(Model), Site, logged(Site, Model, Tower)) :-
    opposable(infer(Model), Site, Tower).

% ---------- QUERIES (inference) ----------

% ?- opposable(infer(diagnostic_inference), site_a, Tower).
% Tower = tower_eu_1     -- only the in-jurisdiction tower qualifies.

% ?- opposable(infer(diagnostic_inference), site_b, Tower).
% false                  -- site_b is processor, blocked from diagnostic.

% ?- effect(infer(diagnostic_inference), site_a, E).
% E = logged(site_a, diagnostic_inference, tower_eu_1).

The regime is the protocol. There is no separate "access control layer" to keep in sync with the model inventory; there is no separate "audit log" that has to be cross-checked against the billing system. The same logic that qualifies an act also qualifies its effect, and the same logic is what the hospital leadership, the IRB, the DPO, and the audit committee all read.

Outcome: One Zone, One Regime, One Audit Trail

The hospital group's deployment consolidated fourteen fragmented governance surfaces into a single Axone Zone. The result, framed in aggregate terms rather than named-testimonial form:

  • → One regime replaces per-site governance. New sites join the same Zone; new models clear review through the same rule; new jurisdictions add predicates rather than new spreadsheets.
  • → Opposable acts. Every qualified clinical inference is contestable and auditable. A clinician or a regulator can submit a counter-act against a logged inference and the regime determines the resolution path — without opening a vendor ticket.
  • → Pactum-style settlement when a region-specific SLA is breached: a site misses a quota threshold, a processor exceeds a jurisdiction, a vendor is late on a ratification — all of these become payable events whose settlement runs against the regime, with reputational and financial consequences, in seconds.
  • → Reduced risk surface. Audit-grade logging is a property of the act type, not a separate platform. Review cycles that used to span departments now close on a single Layer-1 commit.
  • → Operationally reproducible. The Zone Builder turns the regime into a typed, versioned artifact the clinical engineering team can review, patch, and roll forward without re-litigating the authority graph.

AxoneOS did not promise the institution a miracle. It promised — and delivered — that the inference running through the operating theatre on Tuesday is governed by the same rules as the inference running at the outpatient clinic on Friday. That is the threshold an institution crosses when its AI operations stop being a constellation of pilots and become a governed service.

What Zone Builders Mean Going Forward

Healthcare is the most regulator-loaded sector an Axone Zone will plausibly run in. If a regime can survive a clinical IRB, a data protection authority, and an internal audit committee reading the same Prolog file — every other institutional deployment gets easier from there. The Zone Builder is the layer that makes that possible at scale: a typed, versioned, parameterizable artifact an institutional engineering team can ship and revise. The case study above is anonymized for a reason — the partnership is still in negotiation. But the shape of the result is not a forecast. It is what already shipped.