A compliance reviewer should tell an operator exactly which requirement failed, which artifact supports the finding, and what remains unresolved. Its value comes from those inspectable checks, not eloquent review prose.
This article is a design guide alongside Reviewer Agents. The old short function checked local shapes and treated field presence as proof. That is insufficient for current authority, approvals or external effects. The replacement below is an explicit rubric and test plan, not a runnable compliance service or a legal certification.
Separate the reviewer from the enforcement owner
A deterministic validator can inspect a typed artifact. A model-assisted reviewer can suggest findings with uncertainty. Neither authenticates its own inputs or grants itself authority to merge, dispatch or waive policy.
Protected release/approval owners validate exact current evidence and apply their policy. Keep reviewer output separate from atomic operation, approval-redemption and shared-budget stores. A correlated audit record is not the synchronization mechanism.
A local verdict envelope
This illustrative application type is not an additional ContextOS base schema. Required control/report bindings and trusted verification belong to the conformance contract.
type ComplianceReview = {
review_id: string
reviewer_ref: string
proposal_digest: string
policy_refs: string[]
observed_at: string
result: "pass" | "fail" | "insufficient_evidence"
findings: Array<{
rule_id: string
artifact_ref: string
evidence_ref: string
reason_code: string
}>
}At ingestion, validate closed schemas, bounded IDs and arrays, supported versions, timestamp validity, artifact digests and provenance. A boolean such as verified: true, a reviewer name or an evidence_ref supplied by the proposer cannot authenticate itself. Record actual immutable reviewer/policy/configuration pins and current trusted verification observations.
Four initial rules
These C- identifiers are local rubric IDs, not standard ContextOS control IDs. Add feature-specific obligations for the exact admitted profiles.
| Rule | Required check | Insufficient evidence includes |
|---|---|---|
C-001 | Capability native ActionRisk, conservative five-value compatibility projection, current scoped authority and exact stored approval when required | A tier label, requires_approver boolean, frozen evidence hash alone, expired/revoked/wrong-action approval |
C-002 | Eligible data handling at actual collection, inference, tool input/output, telemetry, cache, memory, export and delegation recipients/processors | Classification field presence without current purpose/reader/processor/residency/retention proof |
C-003 | Stable owned operation, actual provider recovery semantics, current worker fencing and honest effect status | An idempotency key with no provider guarantee, missing response treated as absence, reversal token claimed to make an irreversible effect reversible |
C-004 | Exact pinned policy/rule provenance and applicable current authority/control versions | An unresolved or expired policy reference accepted as a harmless warning, unknown operator treated as false |
Canonical DataClassification values are PUBLIC, INTERNAL, CONFIDENTIAL and RESTRICTED. Labels such as PII, PHI or PAN can be separate domain categories; do not add them to that enum. A data label does not establish a legal basis or permission to retain it.
The five ApprovalMode values remain read_only, local_write, network, delegated and destructive. None automatically allows an action or creates a universal requirement for a reversal token. Evaluate all native dimensions and current policy; a read can require approval, and an irreversible effect cannot be made reversible by adding a field.
Build meaningful golden cases
Use complete known inputs and expected reasons. These are proposed cases for an implementation, not a claim that this repository contains the pictured fixtures or runs a reviewer service in CI.
| Case | Expected result and reason |
|---|---|
| Eligible narrow action with current independently verified controls | Pass the checked scope and complete useful work |
| Unknown native risk or non-conservative compatibility projection | Fail the capability check |
| Expired, revoked, wrong-tenant or changed nested action approval | Fail exact approval binding; retain required gate |
| Missing required reviewer/control evidence | Insufficient evidence, blocking dependent release |
| Unapproved telemetry or reviewer processor | Fail before sending protected content |
| Required policy expression throws | Structured compilation error, never permissive else |
| Provider commits but acknowledgement is lost | Effect unknown until reconciliation; no blind new dispatch |
| Old worker resumes after lease/generation change | Reject dispatch under stale ownership |
| Duplicate retry or resumed child | Preserve original effect identity and shared spent/reserved budget |
| Correction/deletion has a pending or externally unknown copy | Do not claim propagation complete |
Add duplicate/conflicting reports, stale artifact digests, synthetic evidence presented as deployed evidence and empty test sets. Test utility as well as denial: a reviewer that blocks everything does not demonstrate a useful operating system.
Route findings into protected change control
Pin the proposal’s complete artifact/release digest and required reviewer set before evaluation. Store eligible bounded findings alongside the proposal, with access control and retention. The proposer cannot select an easier reviewer after a failure or update a referenced artifact without invalidating the review.
Dependent release requires all mandatory controls and current approvals. A failed required check blocks; a missing, stale, synthetic or unevaluated required report is insufficient, not a pass. A human may make an exception only where an explicit governing policy permits that exact exception with current entitled approval. Signing a finding does not waive independent prohibitions, separation of duties or required escalation. An applicable policy-expression error stops compilation visibly.
Reviewers and approvers are actual data recipients. Admit their purpose, tenant/owner scope, processors, retention and exports before disclosure. Do not copy full personal transcripts, credentials or sensitive arguments into every finding. Preserve copy-specific correction/deletion status rather than claiming an append-only log justifies unlimited raw retention.
Keep background review bounded
Scheduled review and consolidation need a current owner mandate. Reviewer model calls, tools, retries and children reserve capacity from the original shared pool, with atomic settlement and no reset on resume. If a review proposes an external change, that is a separately governed effect requiring current action binding, boundary and data controls.
A timeout, cancellation or version rollback cannot prove that an external action stopped or was reversed. Keep the stable operation and unresolved reservation until provider-specific evidence supports reconciliation; current fenced ownership is required for new dispatch.
Maintain the reviewer
Version the rubric, implementation, policy and evaluator inputs together. Add an adversarial or useful regression case when a missed or incorrect finding appears. Inspect false positives and denied useful work by workflow, tenant, language and actual deployment rather than silently deleting an inconvenient rule.
A model-assisted reviewer needs measured repeatability and uncertainty handling; typed output does not make its reasoning deterministic. Independent methods and entitled human/domain review are necessary where the selected requirement calls for them.
Acceptance evidence
The execution contract assigns enforcement owners; control profiles select exact obligations. A conformance report binds the actual workflow, implementation, release, environment, artifacts and trusted observations. Reference validation results do not establish a live sandbox, broker, store or provider guarantee.
Start with a small owned rubric and useful/denied cases. Expand only when the evidence supports the next scope. A four-rule checklist can help discover problems; it cannot certify every regulation, industry or mission-critical deployment.