Concepts

The gate, its policies, its decision records and the review queue serve two callers: AnyBio's own agents, and a third party's application calling /api/v1/govern with its own key. Both are evaluated by the same gate against the same policy model and recorded the same way.

Application

An application is one integration of your AI: a name, a policy scope (a project, or the organization-level active policy), a default mode, and per-channel overrides for sms, app_message, web_chat, voice and email. Applications are managed under /api/v1/govern/applications by an organization admin or an Admin developer key.

Each application has its own application key (gk_...), a server-side secret shown once at mint and hashed at rest. It authenticates only under /api/v1/govern/, is read from the Authorization header only, and is never shipped to a browser or an app binary. Rotation mints a new key and gives the previous keys an overlap window (one day by default, at most seven) before they are refused.

Policy

A communication policy is an authored document: program positioning (wellness or clinical), a review mode (none, on_violation, always), what happens on a violation (allow, rewrite, block_and_review), lists of allowed and prohibited claims, and the claims that require a disclaimer. It is versioned; a new active version supersedes the last for the same scope. Policies are managed under /api/v1/compliance/policies and described in full in the policy model. The policy authoring surface in the dashboard is the Compliance Governance page under Settings.

Decision

A decision is the record of one evaluation, written whether or not the content was delivered. The caller receives allow, hold or block, with the decision id, the mode, the policy and version, reason codes, the rationale, the detected claims and the review state. One decision is recorded per application and turn_id, so a replay of a turn returns the stored decision. The decision id is also the id of the compliance check a reviewer releases, so the id a caller polls (GET /api/v1/govern/decisions/{decision_id}) is the id a reviewer acts on. The compliance record behind it carries the original content, any substituted content, the rationale, the detected claims, the policy, the mode, the would-have decision in observe, and the review state; it is read at GET /api/v1/compliance/checks/{check_id} (Admin scope).

Mode

Per application and per channel: off (not evaluated, nothing recorded), observe (the caller is told allow at once and the gate runs after the response; the record carries would_have, the decision the gate would have made), enforce (the decision is returned inline and binds). A new application defaults to observe. Every mode change is an audited event carrying the actor, the scope, the previous mode and the new mode.

The observe report (GET /api/v1/govern/applications/{id}/observe-report, also as CSV and PDF) summarizes a window of decisions by policy, channel and model. Would-have and enforced counts are kept apart and never combined into a single number.

Hold

A hold is a decision the gate will not deliver until a person acts. It is produced by a block_and_review violation, by a draft the policy would rewrite when the audience is a patient (a patient never receives substituted text), by a policy that reviews every send, by a missing AI-identity disclosure the policy requires, and by a missing policy (the gate fails closed). If the gate does not answer within the inline budget in enforce, the answer is hold with gate_unavailable.

A held record sits in the dashboard's Review Queue. A signed-in person releases it with POST /api/v1/compliance/checks/{check_id}/release or rejects it with .../reject; the record moves to released_after_approval, release_delivery_failed, or rejected_after_review, so the trail never claims a delivery that did not happen. A third party's application learns the outcome by polling the decision or by the signed webhook to its webhook_url; once released, the decision carries released_content.

Per-patient state is checked before the gate, keyed on a hash of the caller's patient_ref: in enforce, a turn to a patient who opted out, withdrew consent, or has no consent on a channel that requires it is block, and a turn over the per-patient frequency cap is hold. Consent and opt-out are recorded under /api/v1/govern/patients/.

A stopped draft is one of two classes, named by stop_class: never_sendable (a prohibited claim from the policy, or a draft telling a patient to start, stop or change a medication or dose), which a reviewer cannot release, and uncertain (held because nobody has read it yet), which a reviewer can release.

When a patient-audience turn is stopped, the decision carries send_holding_line: true: send your holding line now, the fixed text your clinical owner wrote in advance saying that a person will reply, when, and what to do if it is urgent. The text is yours and is never model-written; Govern never sends it for you. Send at most one holding line per decision id.

Route to a person

evaluate accepts the patient message the turn answers, as inbound. It is screened by the deterministic red-flag floor the SMS interview runs, restricted to the categories the application configured (cardiac, respiratory, neuro_stroke, self_harm). A match sets route_to_human: true, independent of the decision: a clean draft is allow with a person brought in, a violating draft is hold as well. In enforce, a match or a hold opens a hand-off, or joins the one already open for the same application and patient reference, routed by the application's handoff_routing. The customer's team works it under /api/v1/govern/handoffs or in the console review queue. In observe, a match is recorded as would_have_routed and nothing is opened.

Inside AnyBio's own programs, the same red-flag screen and the care hand-off are documented under Run a program.

What the gate is, and is not

The gate is deterministic term and claim matching against the policy plus a disclosure check; it catches what the policy names, and only that. It is stateless and fails closed. Nothing on this portal describes it as semantic.

The words

Evaluate, allow, hold, block, observe, enforce, record. A person reviews, releases, rejects, claims, resolves. We do not say a message is compliant or certified, we do not quote a percentage, and nothing here is autonomous.