The observe engagement

An observe engagement answers the question a health system's AI review asks of a vendor: what can your AI say, what stops it, and who sees the record. It runs on an application in observe mode: every draft is evaluated and recorded, and your AI is never blocked. This page says what happens in that engagement and what you get.

What it runs on

• The gate and its decision records (the policy model).
• A sandbox organization of your own, with a policy authored to your positioning and claims, and synthetic patients.
• An application in observe mode, with its own key. Your server calls POST /api/v1/govern/evaluate on each draft, or POST /api/v1/govern/transcripts with a batch of past turns, and each is recorded with the decision the gate would have made.
• The review queue in the dashboard, where held decisions wait for a person and are released or rejected with a note.
• The observe report, GET /api/v1/govern/applications/{id}/observe-report, also as CSV and PDF.

How the two weeks run

1. Policy. Together we write your communication policy: positioning, what happens on a violation, the prohibited phrases in the words your model actually produces, the phrases that require a disclaimer, and the review mode. It is validated (POST /api/v1/compliance/policies/validate) and activated for your sandbox project.
2. Drafts. Your application sends representative drafts your AI would send - synthetic or de-identified, never real patient text - through the gate in observe mode. Every draft produces a decision record with the original content, the rationale, the detected claims and the would-have decision, exactly as a live send would.
3. Review. Your reviewers read the would-have decisions for the period. To see what the hold-and-release loop asks of a team, switch a sandbox channel to enforce: held items then wait in the review queue, and reviewers release or reject them with notes.
4. Adjust. Policy versions are immutable; each change is a new version, and each decision names the version it was evaluated under, so a policy change mid-engagement is visible in the record rather than rewriting it.

What the reviewer receives

• The observe report for the period, as JSON, CSV or PDF: decisions by would-have outcome, broken down by policy and version, by channel and by the model your application named, with would-have and enforced counts kept apart.
• The decision records for the period: per draft, the channel and audience, the decision, the rationale, the detected claims, the policy version, and the review state with the reviewer's action and notes.
• The policy versions in force during the period, as the API returns them.

None of these contains a score, a percentage, or a verdict that anything is compliant; they say what the gate did and what a person did after.

What the engagement is not

It is not a certification and it is not a claim about your model. It shows, on your drafts and your policy, what the gate allows, holds and blocks, and it produces the records a committee can read. Whether that is sufficient for a given review is the committee's call.