ZX-WTWR-01
Watchtower Governance Architecture
00 Document control
Specification: ZX-WTWR-01 · Contract version: 1.0.0 · Status: normative review candidate, not an approved production deployment.
Principle: Agents watch. The platform governs. People decide.
This package specifies the production end-state, including failure, recovery, retention, concurrency, audit, privacy and release controls. There is no reduced MVP conformance profile. The requested specification identity and WTWR-REQ namespace are newly authored here; repository admission is a separate act. The schema URLs are canonical candidate identities, not a claim that these URLs have been published.
The binding source set is the September 2026 editions of ZAI-WATCH-PF, ZAI-GOV-PF, ZAI-POL-PF and TG-AUDIT-PF (see: Google Drive). Page references refer to PDF page numbers. governance/source-register.json records source hashes and inspected repository paths. Repository inspection is pinned to commit d7404177c6e1c9373c9c0c05f2fc4850201112f6 of viroway-ltd/zayaz-docs. Historical conversation content informs the requested use cases; it is not evidence of repository approval.
The document governs a cross-platform monitoring capability. verification-assurance is an existing module ID used here for the specification's assurance scope; this does not assign every future runtime component to that module. Each executable component requires exactly one registry-approved owning module and separate component identity. No new Watchtower module, engine identifier, CSI or artifact-domain namespace is asserted by this document. See the admission checklist for the concrete remaining registry bindings.
01 Purpose and normative language
Watchtower continuously compares authorized work objects with registered obligations, client-adopted commitments, governed rules, collection duties and control-level competence evidence. It produces explainable, non-operative observations and findings. Where sufficient governed information exists, the platform prepares remediation proposals for human review and confirmation.
SHALL and SHALL NOT are mandatory. SHOULD identifies a recommendation with an explicitly documented deviation. MAY denotes permission within all other requirements. Sections 01–27 and Appendices A–F are normative except tables explicitly labeled informative. Appendix G is informative and derives no independent authority. The numbered requirements in Section 24 are stable; explanations elsewhere refine their implementation rather than creating exceptions. Removal deprecates an ID, never recycles it.
Conformance requires all applicable requirements, schema validity, semantic validity, authorization enforcement and production acceptance evidence. A schema-valid object is not thereby authentic, authorized, true, current, complete or admitted. The package validator is a contract test aid; it is not the production authorization service.
02 Architectural position
Watchtower has three cooperating planes:
- Compliance context: the Tenant Compliance Context Projection (TCCP) derives an exact, tenant-scoped compliance graph and retrieval index from existing canonical objects.
- Observation: the Watchtower Observation Fabric (WOF) supplies eligible work-object snapshots and change signals through read-only adapters, CMCB and scoped scan requests.
- Evaluation and recording: deterministic Sentinels and governed AI Observers return non-operative outputs; a separate deterministic recorder admits them, manages finding history and exposes evidence.
The architecture adds monitoring records, not another authority for requirement meaning. Pergamum Pulse owns registered requirement semantics; the policy subsystem owns issuance/adoption; SSSR owns canonical signal meaning and resolution bindings; ZSSR coordinates governed runtime resolution; FOGE compiles interaction contracts; TrustGate governs trust decisions; ALTD/DAL preserve assurance evidence. None of these authorities transfer to Watchtower.
Canonical obligations / adopted policies / governed rules / calendars / competence
|
TCCP snapshots
|
Read-only WOF snapshots --> scheduled execution --> Sentinel or Observer
|
non-operative response to runner
|
deterministic validation and recorder
|
finding + grounding + coverage + history
|
authorized human triage / proposal review
|
owning service confirmation -> operative transaction
An Observer does not write a finding, evidence record or ledger entry. “Raises a finding” in the public brief describes the capability's outcome: trusted platform services validate and record the returned observation. This resolves the public read-only guarantee without granting watchers hidden persistence privileges. [WTWR-REQ-0001, WTWR-REQ-0007–0008]
03 Published-commitment conformance
The four supplied briefs are binding product commitments for this package. Existing constitutional and component specifications constrain implementation. Appendix E maps every substantive commitment family to requirements and acceptance cases; page-group rows include adjacent overview and outcome statements repeating those commitments. Commercial aspirations such as portfolio-scale verification in hours require workload evidence; they are not silently converted into invented universal latency guarantees.
The inspected repository refines the conversation in four material ways:
| Topic | Required implementation |
|---|---|
| Tenant identity | Use eco_number, canonical entity scope and grants. Do not create canonical tenant_id for gateway convenience. |
| AI re-performance | Raw model output uses RECORDED; exact rule evaluation uses EXACT. Re-execution of a model is optional comparative evidence. |
| FOGE handoff | Use PREP and FOGE-REC 0.2.0 with trusted authority/currentness checks; do not send prose regulations to a questionnaire generator as authority. |
| Component and artifact names | Schema object titles are contract types; runtime components, artifact types and transports require registry admission. ARTID supplies the existing fallback instance namespace. |
The strong workplace-law language in ZAI-WATCH-PF §06 is implemented as a technical prohibition on person evaluation. This specification does not turn it into a blanket legal classification for every deployment. The context-specific classification principle in ZAI-GOV-PF §08 remains intact. No new legal interpretation is introduced.
04 System boundaries and non-goals
Watchtower SHALL NOT update classifications, change factors or calculation methods, amend registers, mark evidence valid, adopt policy, assign training, send supplier requests, reschedule obligations, publish disclosures or sign assurance opinions. A finding confirmation validates the reviewer's disposition of the flag; it does not authorize any of those actions.
Watcher principals cannot acquire authority through model tool output, a queued event, a manifest declaring HUMAN, a human-originated scan or a permissive partner default. A human's scan authorization permits reading and evaluating the specified work; it is not delegated authority to remediate.
Documents, transactions and suppliers may contain personal data. Their allowed object types do not permit evaluative worker histories, person rankings or proxy scores. Subject and context eligibility are checked semantically, not only by the subject enum. [WTWR-REQ-0005, WTWR-REQ-0048–0049]
05 Execution model and recorder boundary
05.1 Execution unit
A MonitoringRun is one bounded execution against a MonitoringPolicy, configuration and frozen scope. A run can contain many watcher-target evaluations. Coverage uses the pair object version × watcher definition version as its accounting unit, so running one of five checks on an object is never counted as fully evaluating the object. Large populations are represented by immutable, hash-addressed manifests and partitioned child runs, not unbounded arrays in one database item.
A trusted scheduler resolves the policy, verifies current authorization, establishes source watermarks and requests the grounding manifest. The run cannot enter RUNNING until authority, scope and baseline pins resolve. Watchers consume immutable authorized snapshots. They return structured output over the bounded invocation response; they do not own message-bus publish credentials, recorder credentials or persistence clients. Model execution travels through the governed gateway. Recorder, gateway logger, context builder and proposal broker are distinct service responsibilities.
05.2 Admission protocol
The recorder SHALL, in order: authenticate the trusted runner; validate the closed envelope schema; verify run/lease ownership and scoped idempotency; resolve exact references and source hashes; recheck tenant/grant/purpose; verify tier evidence and grounding; evaluate surfacing/deduplication policy; atomically append observation/finding events and audit outbox entries; then acknowledge admission. Authorization revoked during processing blocks admission or quarantines the result under security policy. Model-provided IDs cannot select a tenant or ledger destination.
The recorder may create Watchtower monitoring records through its bounded store interface. It cannot invoke arbitrary evidence-chain writes. A separate trusted ALTD/DAL service anchors admitted bytes; model output remains labeled as AI-origin evidence, never promoted into factual authority merely by anchoring.
05.3 Time and consistency
observed_window and reporting periods are half-open intervals: from inclusive, to exclusive. effective_at selects obligations and operative versions for the event period; knowledge_cutoff limits the canonical state known to the run. Source watermarks pin each integration's observed boundary. Stored timestamps use calendar-valid UTC with seconds and at most millisecond precision; unknown offsets and leap-second notation are outside this profile.
This does not promise a distributed atomic snapshot across independent SaaS sources. Where consistency cannot be proven, the manifest records the limitation and the run is not complete for the affected scope. Late-arriving records, retroactive corrections and source deletions create linked reevaluations. Historical runs and their authority decisions remain preserved; historical replay does not require a formerly valid requirement to remain current today. Current-use remediation does require fresh authority. [WTWR-REQ-0002, WTWR-REQ-0019–0021]
06 Grounding, baseline resolution and TCCP
06.1 Authoritative scope first
Resolve the canonical organization/entity profile, jurisdiction, industry, size, period, selected frameworks, applicable conditions and registered requirement versions through their owning services. UNKNOWN applicability produces an indeterminate evaluation and a context/coverage exception; absence of knowledge is not non-applicability. Semantic retrieval only selects relevant material inside the already authorized, applicable set.
Baseline inputs include exact registered requirements and authority receipts; adopted policy clauses and obligation mappings; operative procedure versions; classification, validation and calculation rule versions; collection obligations with owner/deadline; control-level acknowledgment and training projections; and source record snapshots. Partner-issued templates are not client adoption. Proposed revisions remain proposals even when the regulation has changed. A new regulation can therefore produce a policy gap while the old client policy remains its exact historical commitment.
06.2 Projection contract
TCCP stores derived references and search representations, not competing interpretations. Each graph node and retrieval chunk resolves to canonical ID, version, source hash, locator, effective interval, access scope and module/component lineage. Its manifest pins chunking, lexical retrieval, embedding model, authorization snapshot and source watermarks. Embedding execution is governed AI too. No shared cross-client index or cache entry may bypass E-C-O and grant filtering.
Filtering occurs before candidate retrieval and again before content release. A source deletion, permission revocation, authority withdrawal, substantive adoption or baseline change invalidates affected slices, embeddings, caches and scheduled dependency work. Historical grounding remains under its lawful retention/access policy. A READY projection is a performance aid; execution must still validate authority, freshness and access. STALE/INVALIDATED projections cannot silently ground current findings.
06.3 Frozen grounding
GroundingManifest is an immutable snapshot of configuration, applicability, exact baselines, source snapshots, retrieval trace, selected and excluded chunks, source hashes and authority receipts. baseline_digest covers a canonical sorted list of exact baseline references plus applicability/effective-time context. The retrieval trace records queries, algorithms and versions, candidate selection, exclusion reasons and authorized results; retain it as a governed blob, not unstructured hidden model memory.
06.4 Policy and training continuity
The owning policy service classifies a change as substantive or editorial through a named reviewed decision. A regulatory-derived revision is substantive. Watchtower observes the appropriate version-bound coverage; it never resets acknowledgments itself. Editorial updates preserve valid acknowledgment lineage. Awareness and competence have separate denominators and evidence: “read” must not be displayed as “understood.” [WTWR-REQ-0014–0016, WTWR-REQ-0037–0039]
07 Canonical object model
JSON Schema Draft 2020-12 is the canonical serialization dialect. Individual files live under schemas/watchtower/1.0.0/; schema-catalog.json lists every exact schema identity. Each persistent candidate record includes schema_version, object_type, ARTID id, monotonically increasing integer version, eco_number and recorder provenance. ExactRef versions preserve source-native versions; references to Watchtower integer revisions use their decimal string form.
| Object | Responsibility |
|---|---|
| WatchtowerConfiguration | Human-approved effective settings and governing policies, including privacy, retention, resources and service levels. |
| MonitoringPolicy | Scope, watcher set, trigger modes, population/dependency selectors, surfacing and proposal-preparation rules. |
| SentinelRule | Governed deterministic executable, parameters, exact runtime image and test/replay contract. |
| Observer | Governed prompt/instruction, model capability, input/output, retrieval and calibration contracts. |
| MonitoringRun | Frozen execution context, state, watermarks, attempts, coverage and observations. |
| CoverageManifest | Enumerated evaluation units, disjoint outcome partitions, totals, exclusions and source reconciliation. |
| ObservationEnvelope | Admitted non-operative evaluation output with exact tier, source/run/grounding lineage and idempotency. |
| Finding | Versioned review projection of a grounded issue, its epistemics, history, visibility and consequences. |
| FindingGrounding | Source locators, baselines, authority evidence and claim-to-source relationships. |
| FindingEvent | Immutable attributed event, sequence, expected revision and hash-chain linkage. |
| SuppressionDecision | Human-authorized, scoped, expiring notification suppression independent of triage. |
| RoutingPolicy | Ordered client/partner routing, grant requirements, fallback and escalation. |
| RemediationProposalRef | Read-only linkage to a separately governed proposal and its external confirmation/results. |
| FindingFingerprint | Exact deterministic identity projection for deduplication; not a similarity embedding. |
| TenantComplianceContextProjection | Rebuildable graph/retrieval projection with exact lineage and invalidation state. |
| GroundingManifest | Immutable run-level baseline, applicability, source and retrieval snapshot. |
| ObservationAdapterManifest | Approved WOF capabilities and source snapshot/watermark/deletion contracts. |
| ConsequenceGraph | Exact versioned impact traversal with governed versus hypothetical edges and completeness. |
| AIExecutionRecord | Correlation to the canonical AIExecutionEnvelope and replay manifest, not a replacement for either. |
common.schema.json closes shared value types. Arbitrary extension maps are deliberately absent. An extension requires a versioned schema change. Actor identity fields exist only for accountability. No schema provides a person-scoring subject or record.
07.1 Semantic admission constraints
After structural validation, the service SHALL verify:
- All references exist with matching type, exact version and digest. Tenant references match the root E-C-O; platform references resolve to genuinely global governed objects, not tenant data mislabeled global.
- Nested Scope E-C-O, entities, periods and grants agree with the root and authenticated execution. Scope narrowing must be explicit; no reference may widen it.
- Time intervals are ordered, source versions are valid for the intended effective/knowledge time, and current-use authority receipts are fresh and purpose-bound.
- Counts reconcile: expected = evaluated + excluded + failed + deferred + unavailable. Exclusions require governed justification; they are never evaluated passes. Unknown denominators retain UNKNOWN status regardless of numeric placeholders.
- Every outcome appears exactly once in the immutable coverage partition.
surface_counts.observations = surfaced + suppressed + below_gate + no_finding; surfacing is orthogonal to evaluation coverage. Suppressed matches remain evaluated and auditable. - Claim indices exist; graph node IDs are unique; edge endpoints resolve; graph completeness and unresolved/truncated state agree.
- Finding snapshots reduce from their event chain. Event type, actor, from/to state, expected revision and sequence obey Appendix A. User fields supplied by a client are never authentication proof.
- Fingerprints, manifest hashes, signatures and audit receipts verify against trusted canonical bytes. A SHA-256-shaped string alone proves nothing.
These conditions cannot all be expressed by JSON Schema. They are mandatory service/storage constraints, enumerated in the acceptance matrix. [WTWR-REQ-0020, WTWR-REQ-0022–0024, WTWR-REQ-0058]
08 Finding semantics and consequence graphs
08.1 Epistemics
Tier 1 states a bounded fact: “the deadline in calendar obligation version X preceded the frozen evaluation time and no qualifying submission was present in the covered snapshot.” It does not assert general non-compliance. Tier 2 states a graded observation: “these descriptions appear inconsistent with this classification.” Its confidence grade refers to a governed calibration policy, not a probability of guilt, a worker score or materiality. A named reviewer may confirm the observation; its origin remains Tier 2 forever.
Findings separate severity, confidence, materiality and consequence. Critical severity cannot manufacture high confidence. An uncertain observation may justify urgent human review. Materiality defaults to NOT_ASSESSED and requires a separate policy for any assessed state. Provider private reasoning is not required: persist the evidence-linked rationale, limitations and original returned response, not a claim to inaccessible chain-of-thought.
08.2 Fingerprints
Digest the UTF-8 domain separator ZX-WTWR-01/FindingFingerprint/1.0.0 followed by a newline and RFC 8785 canonical JSON of identity. Sort entity_ids and subject_ids lexicographically as Unicode strings and reject duplicates. All other identity fields are exact and case-preserving. Identity includes E-C-O, entity set, subject kind/stable IDs, control/obligation ID, watcher family and semantic version, tier, baseline digest, period and population-selector digest. It excludes finding title, prose, confidence, severity, routing and source record versions that merely refresh the same issue. Exact source versions remain in each observation.
The population selector must define a stable issue grain, such as one control for one supplier or one governed population for one reporting period. An expanding population appends occurrence evidence to that grain; it does not accidentally merge separate obligations. A changed baseline or watcher semantic version creates a new fingerprint and successor link. Hash collisions or equal hashes with unequal canonical identities quarantine the record; do not merge by hash alone.
08.3 Consequence graph algorithm
Start from the exact observed object and grounded control/requirement. Resolve authorized relationships under the run's effective/knowledge time; traverse dependency edges to adopted clauses, procedures, affected populations, evidence, calculations, disclosures, forms and training. Keep a visited set keyed by canonical object ID/version and relation version, deduplicate repeated paths, and enforce governed depth/node/time limits. Persist nodes, evidence-backed edges, traversal policy/version and unresolved/truncated branches.
Only registered dependency relationships are GOVERNED_RELATION. AI-suggested links remain HYPOTHESIS and cannot determine authoritative affected populations or remediation recipients. Denied nodes are omitted from the reader projection; return an access-filtered completeness notice without leaking their IDs. No missing edge is invented to make the graph appear complete.
An Observer consequence is POTENTIAL_IF_CONFIRMED unless supported by independent deterministic evidence. Quantified impact is produced by a separate governed calculation/preview with exact methods, factors and input versions and a clear non-operative label. Watchtower does not write a revised reported number. [WTWR-REQ-0003–0004, WTWR-REQ-0024, WTWR-REQ-0035–0036]
09 Lifecycle state machines
Finding triage, notification visibility and remediation proposal state are separate axes. SUPPRESSED is not a triage state. CONFIRMED is not remediation consent. A proposal may be prepared before human triage where an approved preparation policy permits it, but it stays inert.
MonitoringRun follows REQUESTED → RESOLVING → RUNNING → FINALIZING → COMPLETED or PARTIAL. Failure/cancellation can interrupt any nonterminal state; all terminal states preserve coverage, including an unknown population when resolution failed. COMPLETED means all selected evaluation units are evaluated or explicitly excluded under policy, not that there were no findings. PARTIAL includes failed/deferred/unavailable units or incomplete population knowledge. New attempts use fenced execution leases and linked run versions; terminal snapshots are immutable.
Finding follows RAISED → ROUTED → TRIAGE_PENDING → CONFIRMED or DISMISSED. Confirmed findings may enter REMEDIATION_PENDING, then RESOLUTION_PENDING and RESOLVED. A human may request resolution directly if no remediation is necessary, with evidence and reason. The recorder never infers resolution solely from a no-match. A resolved finding that recurs appends an occurrence and notifies the review queue; human REOPEN creates REOPENED → ROUTED. A dismissed recurrence remains dismissed pending human reopening, while the new evidence remains visible. A new baseline creates a linked successor and SUPERSEDED administrative event; this does not count as resolved or dismissed.
A monitoring-control failure is operational evidence. It is not mislabeled as a substantive supplier or policy violation. If a separate rule monitors the monitoring service itself, that rule has its own governed subject, grounding and evaluation.
Configuration and definition versions follow DRAFT → REVIEW → ACTIVE → RETIRED; configuration also permits ACTIVE → SUSPENDED → ACTIVE under a newly authorized revision. Activation requires a human approval digest bound to the exact bytes; resumption must recheck current policy. Proposal linkage follows REQUESTED → PREPARING → DRAFT_READY → IN_REVIEW → CONFIRMED_EXTERNALLY or REJECTED, with WITHDRAWN/SUPERSEDED alternatives. The owning proposal service is authoritative for those transitions. [WTWR-REQ-0006, WTWR-REQ-0023, WTWR-REQ-0025]
10 Permission and identity model
Use workload identities for trusted services and non-transferable human session/delegation evidence for human decisions. The authenticated server context determines actor kind, E-C-O, permitted entity scope and role; actor JSON is a recorded representation of verified identity. A service acting on behalf of a person is not automatically a human confirmer. Confirmation requires the current human session and an authorization receipt bound to exact reviewed bytes.
Read authorization checks both a historical scope snapshot for provenance and current access for retrieval/delivery. Purpose, data classification, region, period and delegation form part of authorization. Natural-person ownership metadata may be exposed where needed for control accountability; it cannot become evaluative subject matter.
No principal shares both watcher and recorder credentials. No recorder principal shares operative remediation permissions. Watcher and AI identities cannot call the human triage endpoint even with a fabricated human field. Auditors receive verification operations only; platform storage remains inaccessible. Appendix C specifies the required denials. [WTWR-REQ-0001, WTWR-REQ-0007, WTWR-REQ-0013, WTWR-REQ-0049]
11 Work-never-worker and user experience
Context assembly minimizes personal data before retrieval and model invocation. Competence inputs contain policy/control/unit, exact required version, required population count, completion count, period and governing coverage policy. They do not contain employee error histories. Small cohorts and repeated overlapping queries can reveal individuals even without names; the privacy policy must govern cohort minimums, differencing protection, restricted drill-down and suppression of identifying aggregates. These parameters require governed policy, not invented fixed thresholds.
A sole trader or a document nominally about a person is not automatically an eligible supplier/work object. The eligibility resolver must distinguish legitimate organizational/control evaluation from person evaluation and minimize identifiers. No output should rank employees by non-conformance, correlate personal mistakes, or recommend disciplinary action.
Personalized navigation is a separate authenticated UI projection, retrieved from the owning policy/training service for the current user. It is not persisted as a Watchtower performance profile or fed back to the Observer. Three link classes are explicit:
| Link class | Behavior |
|---|---|
| Information | View policy, change summary, requirement or finding. No state transition. |
| Existing required action | Navigate to an already assigned acknowledgment or Academy/provider module. Completion occurs in its owning service. |
| Proposed new action | Review a proposed training assignment, policy amendment or evidence request. Human confirmation remains required. |
For completed users, show “Your requirements are complete” with unobtrusive view links. Keep the organizational finding visible to authorized owners/managers without implying the user personally failed. Existing policy-service reminders remain governed there; Watchtower must not create competing reminder loops. [WTWR-REQ-0005, WTWR-REQ-0039–0040]
12 Precision and noise governance
Tenant-approved policies govern severity, calibrated confidence gates, materiality, notifications and escalation. Below-gate observations remain in monitoring evidence and surface counts. They do not silently disappear from coverage. UNRATED outputs must use an explicit manual-review path or remain below gate according to policy; they cannot be displayed as high confidence.
Suppression requires a human decision-maker, exact selector, baseline digest, watcher family, severity cap, reason, review time and expiry. Effective time must precede review and expiry. Renewals are new decisions. Expiry or changed applicability causes deterministic re-surfacing, not human triage. A suppressed notification remains an existing finding and continues to accumulate observations. Tenant administrators cannot suppress audit history or turn coverage failures into clean results.
False-positive feedback is a versioned review outcome. It informs an approved tuning/release process; it is not online self-training on client content. Queue health measures unresolved age, routing failures, calibrated false positives and reviewer backlog at control/unit level. It must not generate employee productivity rankings. [WTWR-REQ-0026–0028]
13 Routing architecture
Evaluate RoutingPolicy rules in ascending unique priority; first match selects the explicit destination set. A rule can target both client and partner queues. An engagement reference and current grant are mandatory for partner delivery. Unmatched findings go to the client fallback queue; missing fallback is a configuration error, never silent loss. Deduplicate destination references and record routing policy/version, decision and delivery receipts.
Notifications contain the minimum approved summary and a scope-authorized link. Every click and every export rechecks current authorization. Delivery retries use payload-bound idempotency and a governed escalation policy. Partner portfolio views remain per-client grant projections; portfolio membership alone is not a read grant. External assurance visibility is served through the audit channel, not partner operational queues. [WTWR-REQ-0029]
14 Governed AI integration
The execution path follows the inspected AI-DIAL contract: ZADIF dispatch, task/context assembly, AIGS governance, CUEM preflight where applicable, GRPE region decision, governed execution adapter, regional AI DIAL, approved deployment, output governance, metering and ALTD/DAL evidence.
Watchtower consumes the canonical AIExecutionEnvelope by exact reference; AIExecutionRecord adds the monitoring correlation. It pins the client AI policy, gateway policy, capability profile, actual model and version, deployment, route attestation, prompts, instructions, source/grounding manifest, inference parameters, request/response bytes and validation result. Unsupported seeds are explicitly recorded; a seed is not proof of deterministic model execution. Each fallback/retry is separately logged with its actual endpoint/version and new authorization evidence.
No region menu is a universal static list. GRPE exposes only contract-permitted cells and revalidates the chosen cell at execution time. DIAL may balance inside that decision; it cannot lower assurance or move data elsewhere on timeout. No external model credentials exist in watcher, adapter, recorder or frontend configuration.
Complete request/response evidence is retained by trusted platform services under scoped encryption and retention rules; secrets are removed before invocation, not erased from history to hide execution. Operational token telemetry is not a substitute for assurance records. Client data is not training data. Disabling Tier 2 cancels pending model dispatch and records deferred coverage; Tier 1 continues where independently enabled. [WTWR-REQ-0009–0012, WTWR-REQ-0052–0054]
15 Confirmation boundary and FOGE handoff
15.1 Separate preparation service
After a finding has eligible grounding and an authorized preparation policy, the deterministic proposal broker requests a draft from the relevant owning service. The watcher cannot invoke that service directly. RemediationProposalRef records affected objects, requirement and policy pins, rationale, exact consequence graph and owner. It remains non-operative even after it references externally confirmed results.
Review packages show original finding, source evidence, potential consequences, proposed changes, affected objects, recipients, costs/side effects where relevant and current authority. Acceptance, amendment and rejection are recorded. Amendments retain the proposed-to-confirmed delta. Human confirmation is payload-bound and independently authorized; it cannot be inherited from a CONFIRM finding event.
15.2 Supplier form preparation
For regulatory-change supplier due diligence, resolve the exact requirement set for each supplier from PREP's published Requirement Execution Package, not from free-text law retrieval. FOGE-REC 0.2.0 controls applicability, obligation, Data Needs, satisfaction, alternatives, evidence, attestation, derivation, estimation and reuse. SSSR owns data resolution semantics; FOGE owns complete form definitions and the minimum interaction projection.
FOGE runs its existing trusted compilation-authority gate. Requirement existence and a caller assertion of approval are insufficient. Check durable admission and fresh current/non-revoked/non-superseded authority, exact package integrity, selected applicability, temporal scope and lineage. Where XBRL mappings are involved, retain the contract's PP-MAP/PP-MD, mapping-direction, condition, target and Rights Gate requirements. Watchtower must not weaken or duplicate that gate.
Each supplier projection pins jurisdiction, industry, products/commodities, relationship characteristics, adopted policy/procedure, prior answers and evidence resolution. Valid reusable evidence must satisfy period, scope, quality and authority constraints. Preserve every Data Need even when it produces no question. Required attestation yields confirmation-only interaction; all satisfied needs with no attestation yield zero interaction. Unknown applicability or unacceptable evidence produces a blocked/unresolved supplier item, not an invented answer.
15.3 Human send and revalidation
“Send all 12” is an explicit human confirmation in the owning governed workflow. Its review package binds each exact form draft, recipient, requirement/policy version and evidence state. The command must also perform any still-required form-definition confirmation before an operative instance is dispatched; request generation alone publishes nothing.
At confirmation, recheck authority, permission, recipient and source/evidence freshness. If anything material changed, regenerate affected drafts and require renewed review. Per-supplier send uses a payload-bound deduplication key and durable external receipt. After partial failure, show successes, failures and unknown delivery states individually; reconcile unknown states before retry. A batch is not falsely represented as atomic across external mail/form systems. New valid evidence received before dispatch may reduce twelve requests to fewer, or zero; do not send redundant forms just to preserve the earlier count. [WTWR-REQ-0030–0034]
16 Audit, provenance and re-performance
Preserve the full chain: canonical authority and adoption → frozen applicability/context → source versions and watermarks → exact watcher/configuration → evaluation and AI call where applicable → coverage → observation → finding/grounding → routing/suppression → human disposition → proposal → external confirmation → operative object versions and downstream use.
Sentinel EXACT replay recomputes the preserved predicate from original inputs, parameters and executable/runtime versions. It compares governed outputs exactly. An environmental fetch is not permitted in place of a missing historical input. Observer RECORDED replay verifies original response, digest, model identity, prompt/input lineage, authority context and creation-time anchoring. Optional model reruns are independent experiments with their own provenance; substantive similarity does not repair a corrupt original record. Future BANDED outputs require a separately approved tolerance profile and contract version, not a local exception to this release.
Audit exports include coverage partitions, suppressed/below-gate observations, failed/deferred checks and history, not only confirmed findings. Re-performance may verify a bounded clean result but never issues the practitioner's opinion. Evidence retention expiry, inaccessible providers or broken lineage produce explicit unverifiable/partially verifiable outcomes. They do not become “passed.” Platform controls support periodic independent examination; this document does not claim such an attestation has already occurred. [WTWR-REQ-0041–0047, WTWR-REQ-0060]
17 API contract
The package includes an OpenAPI 3.1 authoring fragment in api/watchtower.openapi.json. Endpoint names are proposed integration routes and must be reconciled with the canonical ZX-API-01 implementation standard and central API file before publication; that standard was referenced by the supplied brief but not located by repository search. No deployed route is asserted.
All requests derive E-C-O scope from authenticated context. A path ID is never a cross-tenant lookup shortcut. Use exact schema versions, bounded pagination, opaque cursor tokens bound to caller/grant/snapshot, ETags and If-Match for transitions, and payload-bound idempotency for commands. Return 401 for unauthenticated, 403 for forbidden, 409 for conflicting idempotency/state, 412 for stale revision, 422 for semantic invalidity, 429 for governed quota and 503 for unavailable mandatory authority/audit infrastructure. Error responses must not disclose unauthorized object existence.
Read APIs expose findings, runs, grounding, coverage and event history. Scan commands enqueue monitoring only. Triage commands accept a narrow decision and reason; they do not accept caller-supplied actor identity or arbitrary replacement Finding payload. No Watchtower endpoint implements business remediation or supplier send. Proposal APIs return references to the owning service's review flow.
The assurance API checks provider registry, client appointment, engagement grant, conflict registry and current runtime policy on every call, page, download and async-result fetch. Scope includes entity/group, period, framework, datapoint/evidence classes, snapshot versus rolling mode, purpose, caller and validity. A declared preparer-network conflict blocks access. Read-only verification jobs may create audit-job records in trusted platform services, never client business mutations. [WTWR-REQ-0042–0044, WTWR-REQ-0049]
18 Atlas configuration
Atlas exposes enabled tiers/functions, exact watcher packs, severity/confidence/materiality policies, schedules, freshness, resource budgets, region policy, routing, suppressions, retention and version history. A watch pack is a governed list of existing SentinelRule/Observer versions through MonitoringPolicy; it is not a new authority layer.
Configuration resolution intersects platform restrictions, client contract/AI policy, authorized partner defaults and explicit tenant settings. Lower layers may narrow permissions, never relax hard limits. Resolve the effective snapshot before scheduling and revalidate security-critical permissions at use time. Partner defaults do not silently activate AI for an unconsenting client. Configuration approvals bind the exact candidate digest. Emergency suspension is attributable and blocks new work without deleting previous findings; resumption is a governed revision.
Atlas must expose the distinction between monitoring disabled, source unavailable, below gate and no matches. Configuration changes and administrative suppression are visible to authorized client administrators and audit grants. [WTWR-REQ-0053]
19 Data architecture and transactional boundaries
19.1 Logical persistence
Persist immutable object revisions plus current projections. Recommended aggregate boundaries are run, finding/event chain, configuration, suppression and preparation request. Store large source, retrieval, outcome and graph manifests as encrypted immutable blobs; tables store exact references, digests and lengths. Tenant/entity/period constraints apply to every table, secondary index, blob path, export and cache key.
A finding append transaction conditionally checks current revision, inserts the event, updates the projection and occurrence/fingerprint index, and inserts a durable audit outbox entry. A unique constraint covers E-C-O plus fingerprint canonical identity. A separate uniqueness constraint covers E-C-O, operation and idempotency key with request hash. Same-key/same-payload retries return the original result; same-key/different-payload requests fail. Leases use monotonic fences to reject stale workers after timeout or failover.
19.2 Audit finalization
The recorder transaction persists bytes plus an outbox entry before claiming acceptance. Until ALTD/DAL anchoring is verified, records remain internally pending and are not emitted as audit-ready canonical output. Canonical schema instances require a ledger receipt; a ledger receipt is resolved externally to the hash of the record with that receipt field excluded, avoiding a circular self-hash. Recorder/service staging objects are internal transaction records, not partially valid canonical objects.
If audit anchoring is down, retain a bounded durable backlog, expose operational degradation, apply backpressure and stop further admission when the governed capacity limit is reached. Recovery retries anchoring idempotently. Never silently drop audit events or allow observers to write them as fallback.
19.3 Retention, deletion and recovery
Versioned retention policy governs source snapshots, original model inputs/outputs, findings, event chains, indexes and exports. Legal holds override ordinary expiry through the owning governance process. Rights revocation immediately removes access and derived search/cache content where required; historical retention is separately assessed. Lawful deletion leaves a non-sensitive tombstone, reason, affected digest/lineage and replay limitation. Do not retain forbidden personal content merely because a hash chain references it.
Backups and disaster recovery remain within GRPE-authorized residency and encryption boundaries. Restore tests reconcile object revisions, outbox offsets, event-chain heads, manifest digests and deduplication state before resuming dispatch. RPO/RTO and availability are explicit governed deployment values, with evidence of restore tests; this specification invents no universal numeric SLO. [WTWR-REQ-0046–0047, WTWR-REQ-0050]
20 WOF events and trigger architecture
Adapters emit trusted work-object change notices through the existing integration/CMCB path. A notice contains source event identity, source object/version, snapshot locator/hash, observed/effective times, source watermark and adapter version. The router does not trust a notification as proof that the source object exists or is accessible. Resolve and verify the snapshot before evaluating it.
Event subscriptions use dependency selectors: changed supplier country, commodity or certificate schedules only affected watcher definitions. Deduplicate source event delivery before it becomes an occurrence. Coalescing is permitted only when the governed policy preserves required intermediate transitions and snapshot evidence; it cannot drop a temporary control breach.
Scheduled jobs cover deadlines, acknowledgment/competence coverage and sources without reliable events. On-demand Scan Now captures a document/work-object snapshot; it does not monitor keystrokes, modify the document or treat unsaved content as an operative policy. Baseline changes invalidate dependent TCCP slices and fan out authorized reevaluations. Initial connection and periodic/full reconciliation enumerate authoritative populations independently of event delivery, detecting missed deltas and source-total discrepancies.
Adapter conformance covers capability denial, source grants, rights, pagination, snapshot stability, deletes/tombstones, watermark ordering, schema evolution, malformed payload quarantine, rate limits and resumability. No connector becomes production eligible merely because it can read a file. [WTWR-REQ-0017–0019, WTWR-REQ-0059]
21 Failure semantics
| Failure | Required outcome |
|---|---|
| Missing/stale source | Preserve last successful watermark, mark affected units unavailable/stale, retry only within policy. |
| Unknown applicability or unadmitted baseline | No substantive pass/fail; record context gap and partial/unknown coverage. |
| Gateway/model failure | No alternative unapproved provider; bounded retry or visible deferral. |
| Integrity mismatch | Quarantine exact payload and halt affected lineage; notify authorized operations. |
| Invalid model output | Preserve returned bytes in restricted execution evidence; reject admission as a valid observation. |
| Partial source pagination | Do not infer denominator or complete coverage; retain continuation and resume fence. |
| Grant revoked | Stop reads/dispatch/delivery immediately; retain permitted accountability evidence. |
| Proposal preparation fails | Finding remains; show preparation failure, never “remediation ready.” |
| DAL unavailable | Durable pending state/backpressure; no audit-ready completion claim. |
| Cancellation | Stop future evaluation; preserve already admitted results and account for remaining units as deferred/cancelled. |
Independent healthy scopes may continue under PARTIAL status. Health notifications go to operational owners with minimal context and must not be converted into false compliance findings about client work. [WTWR-REQ-0021, WTWR-REQ-0051]
22 Production non-functional requirements
Resource policy defines per-client concurrency, event backlog, watcher execution timeout, graph bounds, scan size, model budget, retry/circuit-breaker settings and prioritization. SLO policy defines latency and freshness separately by trigger/risk, availability, recovery and queue review targets. Activation requires numeric values and named accountable owners in those policies. Unbounded queues or implicit provider defaults are nonconformant.
Scale through tenant-scoped partitioning, snapshot reuse, dependency-directed deltas, batch deterministic evaluation, bounded graph traversal and asynchronous full scans. Cache only on complete authorization/context keys. Do not use sampled monitoring to claim full-population coverage. Partitioned scans have a sealed root population manifest and reconcile all child outcomes before declaring completion.
Operational dashboards measure coverage gaps, source lag, model deferral, anchor backlog, queue age, replay drift and rejected unauthorized calls. Separate these from commercial metering and professional assurance judgments. Synthetic/redacted evaluation suites, canary runs and drift reviews measure observer precision; tuning creates a new approved version. [WTWR-REQ-0028, WTWR-REQ-0052, WTWR-REQ-0054]
23 Security and threat model
Trust boundaries include source adapter → snapshot store, runner → watcher, watcher → recorder, dispatcher → gateway/provider, recorder → ALTD/DAL, platform → partner, and client → independent assurance provider. Appendix F assigns abuse cases to controls.
Treat source text as data even when it impersonates a system prompt, policy owner or user. Reject arbitrary tool requests and unauthorized IDs from model output. Resolve evidence through allowlisted governed stores; do not fetch arbitrary URLs from findings, avoiding SSRF and exfiltration. UI renders untrusted content as text and uses authorized navigation targets rather than model-generated executable links.
Require deny-by-default workloads, encrypted transport/storage, bounded tokens, service-authenticated callback paths, signed or anchored provenance receipts, key rotation and authorization checks in storage access layers. Red-team covert person profiles, cross-tenant retrieval, poisoned baselines, malicious suppression, receipt replay across purposes, model substitution, forged human decisions and stale confirmation batches. [WTWR-REQ-0001, WTWR-REQ-0005, WTWR-REQ-0048–0050]
24 Stable normative requirements
The requirement register below is reproduced from governance/requirements.json. governance/verification-matrix.csv gives one acceptance case per requirement, the source basis and verification level. The register is authoritative for the stable IDs; editing either representation requires consistency validation.
WTWR-REQ-0001 — Watcher capability
Watcher principals SHALL have read-only access to authorized snapshots and SHALL possess no operative-write, evidence-write, ledger-write, triage, confirmation, or outbound-remediation capability.
WTWR-REQ-0002 — Frozen authority
Every execution SHALL pin exact versions, hashes, applicability decisions, effective time and knowledge cut-off for every normative baseline used.
WTWR-REQ-0003 — Sentinel epistemics
Tier 1 SHALL evaluate explicit governed predicates using preserved inputs and rule/runtime versions under EXACT replay; a fact is limited to that predicate and scope.
WTWR-REQ-0004 — Observer epistemics
Tier 2 SHALL remain a graded observation with exact Observer, model execution, confidence policy, evidence rationale and limitations; human confirmation SHALL NOT relabel it Tier 1.
WTWR-REQ-0005 — Work never worker
No finding, fingerprint, consequence assessment or monitoring population SHALL evaluate, profile, rank or score natural persons or person-proxy cohorts.
WTWR-REQ-0006 — Human triage
CONFIRM and DISMISS SHALL require an authenticated, authorized non-AI human user, an attributed reason, evidence context and optimistic concurrency.
WTWR-REQ-0007 — Recorder separation
Only a separate deterministic recorder service SHALL admit validated observations and append Watchtower records; it SHALL have no operative business-write or model-execution permissions.
WTWR-REQ-0008 — No operative findings
Finding and ObservationEnvelope SHALL be non-operative records; no detection, routing, suppression or triage event SHALL itself mutate business data or authorize remediation.
WTWR-REQ-0009 — Gateway-only AI
All Watchtower AI, including retrieval embeddings and remediation preparation that uses models, SHALL use ZADIF and the governed AI-DIAL path with no component-owned provider credentials.
WTWR-REQ-0010 — Governed AI execution
Every model execution SHALL bind approved capability and exact model/deployment versions, AIGS decision, current tenant AI policy, GRPE route, region and CUEM preflight where applicable.
WTWR-REQ-0011 — Complete call provenance
Trusted platform services SHALL preserve every AI request/response and attempt with hashes, inference parameters, prompt/instruction pins, validation outcome, lineage and creation-time audit anchoring.
WTWR-REQ-0012 — No model training
Client content SHALL NOT be used to train or improve models; this SHALL apply to providers, gateways, caches and internal tuning pipelines.
WTWR-REQ-0013 — Canonical tenant identity
Tenant isolation SHALL use canonical eco_number and governed entity/grant scope; a provider tenant identifier SHALL NOT become a parallel business identity.
WTWR-REQ-0014 — Authority before retrieval
Authoritative applicability SHALL be resolved before semantic relevance; unresolved applicability SHALL remain UNKNOWN and SHALL NOT become false or be inferred by a model.
WTWR-REQ-0015 — Derived projection
TCCP SHALL be a rebuildable, non-authoritative projection of exact canonical objects, with deterministic graph and access-filtered retrieval index; no orphan chunk may ground a finding.
WTWR-REQ-0016 — Projection invalidation
Canonical adoption, authority, rights, grant and source changes SHALL invalidate affected TCCP slices and schedule dependency-directed reevaluation; historical manifests SHALL remain immutable.
WTWR-REQ-0017 — Observation modes
WOF SHALL support event, scheduled, on-demand, baseline-change and full-reconciliation modes through governed monitoring policies.
WTWR-REQ-0018 — Adapter capabilities
Each WOF adapter SHALL declare approved read/snapshot/event capabilities and SHALL NOT modify sources, send remediation or capture keystrokes or behavioral telemetry.
WTWR-REQ-0019 — Time consistency
Runs SHALL freeze observed window, source-specific watermarks, effective time and knowledge cut-off; non-atomic sources SHALL disclose consistency limits and late-arriving data.
WTWR-REQ-0020 — Coverage accounting
Every terminal run SHALL carry a CoverageManifest accounting for every selected object-version × watcher-version outcome, including failures, deferrals, exclusions and unavailable sources.
WTWR-REQ-0021 — No false completeness
Zero findings SHALL NOT imply compliance or full coverage; unknown denominators, failed checks and disabled monitors SHALL be exposed explicitly.
WTWR-REQ-0022 — Grounded claims
Each finding claim SHALL resolve to source record versions, locators and exact rule, adopted clause, requirement or calendar obligation with authority evidence.
WTWR-REQ-0023 — Immutable history
Every finding transition and material update SHALL append a chained FindingEvent with actor, reason, evidence, time, idempotency key and expected revision; no history is overwritten.
WTWR-REQ-0024 — Deterministic deduplication
FindingFingerprint SHALL use the specified domain-separated canonical digest, excluding prose/confidence/routing while including tenant, scope, baseline and watcher semantic version.
WTWR-REQ-0025 — Recurrence and supersession
Repeated matches SHALL append occurrences; resolved recurrence SHALL queue human reopening; changed baseline semantics SHALL create linked successor findings without silent dismissal or resolution.
WTWR-REQ-0026 — Suppression governance
Suppression SHALL be a named human decision with exact scope, reason, review date and expiry; it SHALL affect notifications only and SHALL remain audit-visible.
WTWR-REQ-0027 — Suppression invalidation
Expired/revoked suppression, changed baseline, widened scope or severity above its cap SHALL cease matching; no suppression SHALL hide a coverage failure.
WTWR-REQ-0028 — Governed confidence and severity
Confidence, severity, materiality and surfacing SHALL remain distinct; thresholds and calibration SHALL come from versioned governed policies, never hardcoded models or runtime self-tuning.
WTWR-REQ-0029 — Routing boundaries
Routing SHALL resolve deterministically by policy/unit/severity and engagement, recheck current grants at delivery, and retain a client fallback queue; partner access SHALL not imply assurance access.
WTWR-REQ-0030 — Proposal-only preparation
A governed preparation broker MAY request remediation drafts automatically; drafts SHALL remain non-operative in a separate proposal owner and SHALL not use watcher write capabilities.
WTWR-REQ-0031 — Separate confirmation
Remediation SHALL require fresh human confirmation in the owning service, separate from finding triage, with exact reviewed payload/version, reason, authorization and amendment delta.
WTWR-REQ-0032 — FOGE governed handoff
FOGE handoff SHALL pin PREP-published Requirement Execution Package and FOGE-REC schema, compile context and fresh trusted authority gate; Watchtower SHALL NOT reinterpret legislation or publish forms.
WTWR-REQ-0033 — Supplier-specific minimisation
FOGE proposals SHALL use each supplier's governed jurisdiction, industry, products, relationship, adopted policy/procedure and acceptable evidence; satisfied needs SHALL not be requested again.
WTWR-REQ-0034 — Batch confirmation integrity
Batch send SHALL bind exact per-supplier forms, recipients, evidence and requirement versions; retries SHALL not duplicate successful sends and partial failures SHALL be visible per item.
WTWR-REQ-0035 — Consequence resolution
Each finding SHALL reference a versioned, scope-filtered consequence graph with governed edges distinguished from hypotheses, cycles bounded and incomplete traversal disclosed.
WTWR-REQ-0036 — Conditional consequence
Observer consequences SHALL be presented as potential if confirmed unless independently evidenced; no speculative calculation SHALL overwrite reported figures.
WTWR-REQ-0037 — Policy adoption authority
Only exact client-adopted policy/procedure versions SHALL be operative Watchtower baselines; partner template issuance and AI drafts SHALL not substitute for adoption.
WTWR-REQ-0038 — Policy change semantics
Substantive policy revisions SHALL follow the owning policy workflow for re-acknowledgment; editorial revisions SHALL preserve valid acknowledgments; regulatory-derived changes SHALL retain substantive classification.
WTWR-REQ-0039 — Awareness versus competence
Acknowledgment SHALL evidence awareness only; competence coverage SHALL use required training/completion evidence separately at unit/control level.
WTWR-REQ-0040 — Non-nagging navigation
Finding UI SHALL distinguish information, existing required action and proposed new action; current-user completion SHALL alter navigation without creating evaluative person objects or repeated unnecessary prompts.
WTWR-REQ-0041 — Replay profiles
Sentinel outputs SHALL declare EXACT and raw observer outputs RECORDED under TG-RP; rerunning a model SHALL not be the RECORDED pass criterion or a claim of deterministic equivalence.
WTWR-REQ-0042 — Audit population access
Audit verification SHALL expose scope-authorized run coverage, provenance, history, integrity and replay across the full population through versioned verification APIs, not raw database access.
WTWR-REQ-0043 — Audit grants
Every assurance call SHALL enforce registry-approved provider, client appointment, caller-bound engagement grant, entity/period/framework/data-class scope, validity, mode and current revocation state.
WTWR-REQ-0044 — Assurance independence
The platform SHALL refuse assurance access where provider or declared network prepared the engaged data for the client/period; a partner routing grant SHALL not bypass the conflict registry.
WTWR-REQ-0045 — Human opinion
Watchtower SHALL expose operating evidence and exceptions, never emit an assurance opinion or a general compliant verdict from absence of findings.
WTWR-REQ-0046 — Tamper-evident persistence
Recorder writes, immutable event revisions and a durable audit outbox SHALL commit atomically; anchoring failures SHALL remain visible and SHALL block audit-ready claims.
WTWR-REQ-0047 — Retention and rights
Retention, legal hold, purpose, access and deletion SHALL follow governed policies across snapshots, prompts, outputs, indexes, caches and exports; expiry SHALL be evidenced without fabricating replay success.
WTWR-REQ-0048 — Prompt injection isolation
Observed documents and model outputs SHALL be untrusted data; embedded instructions SHALL not alter scope, policies, tools, recipients, retrieval authority or confirmation.
WTWR-REQ-0049 — Atomic authorization
Server-derived actor, current authorization and object ownership SHALL be checked at every admission and irreversible boundary; caller-supplied HUMAN or trusted flags SHALL not confer authority.
WTWR-REQ-0050 — Idempotency and concurrency
Admissions, event appends, dispatch and proposal preparation SHALL use scoped payload-bound idempotency with durable uniqueness and fencing; conflicting duplicate keys SHALL fail.
WTWR-REQ-0051 — Failure isolation
Authorization, integrity, authority and residency failure SHALL fail closed; independent healthy scopes MAY continue with explicit partial coverage and no fabricated findings.
WTWR-REQ-0052 — Resource governance
Production SHALL enforce per-E-C-O quotas, concurrency, budgets, cancellation, bounded retries and backpressure without weakening evidence or confirmation requirements.
WTWR-REQ-0053 — Configuration governance
Atlas configuration SHALL use versioned human-approved snapshots with partner defaults constrained by client authority and platform limits; active runs SHALL pin their effective snapshot.
WTWR-REQ-0054 — Controlled release
Rule, observer, model, prompt, adapter and schema changes SHALL pass governed regression, adversarial, tenant-isolation, replay and migration gates; rollback SHALL preserve history.
WTWR-REQ-0055 — Registry admission
Persistent object types, producing components, module ownership, ARTID issuance and CSI transports SHALL resolve through canonical registries before production; schema names SHALL not mint registry authority.
WTWR-REQ-0056 — Stable rules and versions
WTWR-REQ identifiers SHALL never be reused or renumbered; released schema semantics SHALL be immutable and breaking changes SHALL use new versions with explicit migration.
WTWR-REQ-0057 — Source conformance
Each binding published commitment SHALL map to requirements, controls and acceptance evidence; unresolved source conflicts SHALL be explicit admission blockers.
WTWR-REQ-0058 — Semantic validation
Schema validation SHALL be followed by trusted referential, temporal, scope, authority, cardinality, transition and digest validation; shape alone SHALL never admit an object.
WTWR-REQ-0059 — Reconciliation
Initial connection, periodic review and material baseline/configuration changes SHALL support full reconciliation of delta monitoring with independently enumerated source populations.
WTWR-REQ-0060 — Security attestation
IAM denials, gateway controls, recorder isolation, grant revocation, conflict checks and audit integrity SHALL produce evidence for periodic independent platform examination.
25 Verification and acceptance
Contract checks delivered with this package validate all schemas against their metaschema, resolve references locally with no network fetch, validate positive examples, reject deliberate invalid mutations and exercise selected semantic invariants. They also check requirement references, document metadata and source-register integrity.
Production acceptance additionally requires the integration/deployment cases in the verification matrix. In particular, IAM negative tests, real human-session verification, real grant revocation, trusted receipt validation, FOGE send idempotency, provider no-training controls, full Docusaurus/registry lint and disaster recovery cannot be established by sample JSON. A successful local validator does not claim those controls have been deployed or independently attested.
Release evidence must identify tested build, registry snapshots, policy versions, environment, operator, timestamps, results and exceptions. Do not waive a hard read-only, human-only, tenant-isolation, provenance or confirmation invariant through configuration. [WTWR-REQ-0054–0060]
26 AWS reference implementation
This section is an informative deployment mapping, not a new platform mandate. API Gateway with the existing ZAYAZ authentication/delegation layer can expose scoped commands; isolated Lambda/container workloads can implement scheduler, deterministic evaluator, recorder and gateway adapter. CMCB can be backed by approved event infrastructure with retry/dead-letter handling. S3 can store versioned encrypted manifests under immutable/retention controls. DynamoDB conditional writes/transactions or the platform's governed relational persistence can implement aggregate revisions and outbox uniqueness.
The repository also contains PostgreSQL-based governance and FOGE infrastructure. Do not migrate it to DynamoDB merely because the earlier conversation listed AWS services. Storage choice requires an ADR preserving the same transaction, referential, authorization and replay guarantees. Separate IAM roles and resource policies deny watcher writes to tables, buckets, queues and business APIs. KMS and logging policies preserve tenant/residency boundaries. Deployment evidence must prove restrictions end to end, not merely show role names.
27 Delivery and change governance
This authored package is complete as a reviewable architecture/contract release candidate. Production admission requires the explicit entries in governance/ADMISSION.md: document registration and frontmatter checks, component/module ownership, artifact-type/ARTID bindings, CSI definitions, canonical API integration and real enforcement tests. These are deployment gates, not missing MVP features or permission to relax the contracts.
All schema versions are immutable after release. Additive changes still require compatibility evaluation because consumers validate closed objects. Breaking changes require a new major schema version and explicit migration. Preserve old schema bytes, examples and replay resolvers. Never edit historical objects into current semantics. Migration creates attributed successor versions with source hashes and idempotent checkpoints.
Change review covers source conformance, privacy, permissions, state machines, confidence calibration, replay, service contracts and registry lineage. Rollout uses governed canaries; rollback restores approved configuration/definition versions without deleting findings or AI-origin provenance. [WTWR-REQ-0054–0057]
Appendix A — State transition tables
A.1 Finding events
| Event | From | To | Initiating authority |
|---|---|---|---|
| RAISE | none | RAISED | Recorder, on validated match |
| ROUTE | RAISED, REOPENED | ROUTED | Deterministic routing service |
| QUEUE_TRIAGE | ROUTED | TRIAGE_PENDING | Deterministic queue service |
| CONFIRM | TRIAGE_PENDING | CONFIRMED | Authorized human |
| DISMISS | TRIAGE_PENDING | DISMISSED | Authorized human, reason required |
| PREPARE_REMEDIATION | CONFIRMED | REMEDIATION_PENDING | Deterministic broker under approved preparation policy |
| REQUEST_RESOLUTION | CONFIRMED, REMEDIATION_PENDING | RESOLUTION_PENDING | Authorized human, resolution evidence |
| RESOLVE | RESOLUTION_PENDING | RESOLVED | Authorized human, fresh supporting evidence |
| REOPEN | RESOLVED, DISMISSED | REOPENED | Authorized human, new occurrence/evidence |
| SUPERSEDE | any state except SUPERSEDED | SUPERSEDED | Deterministic recorder, verified baseline successor; human may initiate |
| OCCURRENCE, ADD_EVIDENCE, PROPOSAL_LINKED | any state except SUPERSEDED | same state | Authorized platform service or human; no implicit triage |
| SUPPRESSION_APPLIED, SUPPRESSION_EXPIRED | any state | same state | Deterministic service applying an existing human decision/expiry |
Supersession must reference a distinct successor with a new semantic baseline/fingerprint. It never erases the old disposition. An early draft proposal is linked with PROPOSAL_LINKED and leaves the finding in its existing triage state. Routing delivery retries do not replay ROUTE transitions; they are idempotent delivery attempts under the recorded route decision.
A finding's event sequence starts at 1 with no previous hash. Each subsequent event increments by one and binds the preceding hash. Every event has its own immutable ARTID and version: 1; sequence belongs to the finding aggregate, not the event's object version. Every event advances the finding projection revision by one, so expected_version = sequence - 1 and the resulting Finding version = last_event_sequence = sequence. event_sha256 uses RFC 8785 of the event excluding its own event_sha256 and provenance.ledger_receipt_ref; the ledger anchors this digest with the excluded receipt. The service checks the expected prior finding revision atomically. Timestamps cannot order events more strongly than sequence and transaction receipts.
A.2 Configuration, runs and suppression
Configuration/definition activation requires approval over the exact digest excluding approval and ledger receipt, with approved identity/version distinct from later amendments. Retired versions remain resolvable. Run transitions and terminal-state coverage are defined in §09. An ACTIVE suppression becomes EXPIRED by clock or REVOKED by an authorized human decision; neither changes the finding's triage state. Reinstatement is a new decision, not editing the expired one.
Appendix B — Schema conventions and validation boundary
The schema catalog contains 19 object schemas plus one common definition file. All objects are closed. External blobs and exact references require content integrity, access and type verification. scope: PLATFORM may be used only for truly shared governed objects; it does not legalize tenant data reuse. ARTID body grammar here is an authoring contract restriction within the existing ARTID namespace; issuance still requires the canonical identifier/artifact registry binding.
Source-specific shape contracts remain owned by their sources. A BlobRef deliberately references a separately governed manifest; the admitting service must resolve and validate that manifest's exact registered schema. This avoids embedding arbitrary source payloads into Watchtower schemas. The AI replay manifest, AIExecutionEnvelope, Requirement Execution Package and operative form definitions remain canonical external contracts.
Object digests use RFC 8785 canonical JSON and SHA-256 over their declared hash-excluded projection. ExactRef digests refer to the target's declared canonical digest, never its transport formatting. Blob digests cover exact bytes. Graph digests exclude graph_sha256 and the ledger receipt; projection digests exclude projection_digest and the ledger receipt. Observation output_sha256 covers the watcher payload (run/watcher/scope/subject/source pins, evaluated time, tier, result, tier evidence/failure and grounding reference), before recorder metadata. Implementations must publish hash test vectors before runtime admission.
Appendix C — Permission matrix
| Principal | Scoped snapshot read | Return observation | Persist WT records | Append ledger through trusted service | Triage | Prepare draft | Confirm/send operative change |
|---|---|---|---|---|---|---|---|
| Sentinel/Observer watcher | Yes | Invocation response only | Deny | Deny | Deny | Deny | Deny |
| WOF adapter | Authorized source snapshot | Source event only | Deny | Via integration logger only | Deny | Deny | Deny |
| Trusted runner/context builder | Yes | Submit authenticated output | Bounded run staging only | Via trusted logger | Deny | Deny | Deny |
| Deterministic recorder | Admission-required evidence | Validate | WT stores only | Bounded audit outbox | Persist human command only | Deny | Deny |
| Proposal broker/owner | Authorized context | Not a watcher | Proposal/link store only | Via trusted logger | Deny | Yes, non-operative | Deny without distinct human confirmation path |
| Authorized client human | Per grant | Request scan | Commands through services | Attributed by service | Yes | Request/review | Owning-service permission only |
| Partner human | Engagement grant | Request scan if delegated | Commands through services | Attributed by service | Only delegated | Only delegated | Separate explicit authority |
| Assurance caller | Audit grant only | Verification job only | Audit-job evidence only | Trusted audit service | Deny | Deny | Deny |
No principal is authorized by this table alone. IAM, current policy and object-level service checks must implement it. Human confirmer and AI proposer are always distinct identities; the owning policy may additionally require separation of human preparer and confirmer.
Appendix D — API resource catalogue
| Proposed resource | Operations | Required boundary |
|---|---|---|
/watchtower/runs | POST scan, GET scoped list | Authenticated scope, monitoring-only permission, idempotency |
/watchtower/runs/{id} | GET | Current access plus exact run snapshot |
/watchtower/runs/{id}/coverage | GET | Same scope; include failed/deferred/unknown units |
/watchtower/findings | GET scoped list | Server-derived E-C-O; visibility filter does not erase audit history |
/watchtower/findings/{id} | GET | Exact version/ETag and epistemic label |
/watchtower/findings/{id}/events | GET | Ordered immutable history |
/watchtower/findings/{id}/triage | POST confirm/dismiss | Human session, reason, evidence, If-Match and idempotency |
/watchtower/findings/{id}/grounding | GET | Fine-grained source access; no dangling unrestricted links |
/watchtower/findings/{id}/proposals | GET proposal links | No execution or send operation |
/audit/watchtower/reperformance | POST verification job | Audit grant and conflict registry; read-only client data |
Configuration, suppressions, resolution/reopening and proposal confirmation integrate with their governing command services. Their required semantics are specified here, while route registration belongs to the canonical API integration. No unregistered endpoint is claimed deployed.
Appendix E — Binding source conformance matrix
Source labels in the requirement register are WATCH = ZAI-WATCH-PF, GOV = ZAI-GOV-PF, POL = ZAI-POL-PF and AUDIT = TG-AUDIT-PF. Each range below maps to the identically numbered WTWR-TEST acceptance cases; the machine-readable register contains the concrete test procedures and verification level. Repeated summary/outcome claims map to the same controls.
| Source location | Testable commitment | Requirements / mechanism |
|---|---|---|
| WATCH pp.3–4,12 §§00–01,09 | Observe/flag, deterministic operative core, no write/remediation authority | 0001, 0007–0008, 0030–0031; isolated watchers/recorder and external confirmation |
| WATCH p.5 §02 | Six existing grounding sources; exact versions; automatic traceable baseline movement | 0002, 0014–0016, 0037–0039; TCCP and GroundingManifest |
| WATCH p.6 §03 | Distinct exact Sentinels and graded Observers | 0003–0004, 0028, 0041; tier schemas and replay |
| WATCH p.7 §04 | Records, rules/clauses, versions, rationale, consequences, attributed history | 0022–0025, 0035–0036; grounding, graph, events |
| WATCH p.8 §05 | Responsible routing, named triage, proposal boundary, precision and recorded suppression | 0006, 0026–0034; routing, human decisions and inert drafts |
| WATCH p.9 §06 | Work/control subjects, accountability identities, aggregate competence, no person scoring | 0005, 0039–0040, 0048; schema plus context/query controls |
| WATCH p.10 §07 | Gateway/allowlist/region/tenant/logging, impossible write/triage capabilities, auditable runs/coverage | 0001, 0006–0013, 0020–0021, 0046; IAM and trusted recording |
| WATCH p.11 §08 | Engagement-configured client/partner routing and re-performable operating-control history | 0029, 0041–0045, 0059; partner grants and audit API |
| GOV pp.3–5,12 §§00–02,09 | Proposal/operative separation, function boundary map, governed rule authority | 0008–0010, 0030–0032; no authority in model output |
| GOV p.6 §03 | One gateway, exact approved models, region/tenant limits, logged calls, central credentials, no training | 0009–0013; AIExecutionRecord and execution controls |
| GOV p.7 §04 | Real human review, separate proposer/confirmer, amendment/rejection history, versioned outcomes | 0006, 0031, 0034, 0049; payload-bound confirmation |
| GOV p.8 §05 | Client-visible function controls, partner defaults, origin visibility and config history | 0010, 0053; Atlas effective snapshots |
| GOV p.9 §06 | Origin, review, confirmation and downstream lineage queryable through audit | 0011, 0023, 0031, 0042; linked provenance chain |
| GOV p.10 §07 | No AI evidence writes, operative changes, disclosure release, self-confirmation or gateway bypass | 0001, 0007–0009, 0048–0049; permission denials |
| GOV p.11 §08 | Oversight/transparency/logging/privacy and independently examined enforcement | 0011–0013, 0047, 0053, 0060; controls and attestation evidence, no legal-status claim |
| POL pp.3–6,12 §§00–03,09 | Registered obligation → clause → reviewed firm issuance → attributed client adoption | 0002, 0014, 0022, 0037; source lineage without Watchtower adoption power |
| POL p.7 §04 | Per-person/per-version acknowledgments, reminders, coverage and replay | 0038–0040, 0042; canonical policy records, aggregate monitoring projection |
| POL p.8 §05 | Reviewed substantive/editorial distinction; anti-fatigue; substantive regulatory changes | 0038, 0040; consume owning-service decisions |
| POL p.9 §06 | Cross-client clause impact, proposed revisions, review/re-adoption and re-acknowledgment | 0016, 0030–0031, 0035, 0038; traceable propagation |
| POL p.10 §07 | Awareness distinct from training-backed competence; Academy or own provider | 0039–0040; separate coverage and navigation |
| POL p.11 §08 | Policy existence, coverage, currency, competence and responsible identities form audit evidence | 0022, 0037–0042; policy/control provenance |
| AUDIT pp.3–5,13 §§00–02,10 | Explicit versioned logic, full-population re-execution, platform/client/exception layers | 0003, 0020–0021, 0041–0042, 0045, 0060; bounded evidence, not automated opinion |
| AUDIT p.6 §03 | Provider registry, appointment, caller-bound scoped revocable grants, snapshot/rolling | 0042–0043; runtime grant enforcement |
| AUDIT p.7 §04 | Provenance, recomputation, validation, integrity, completeness, history and evidence quality | 0020–0023, 0041–0042, 0059; delegate calculation and L1–L5 quality semantics to owning services |
| AUDIT p.8 §05 | Context-rich exceptions and engagement-specific thresholds | 0022, 0028–0029, 0042; grounded exceptions and governed policies |
| AUDIT p.9 §06 | Preparer/provider-network conflict registry by client/period | 0044; separate operational and assurance grants |
| AUDIT p.10 §07 | Practitioner judgment, engagement acceptance and signed opinion remain human | 0045; no Watchtower opinion object |
| AUDIT p.11 §08 | Read-only, client-visible/revocable access, isolation, logging, credential hygiene, attestation | 0043–0044, 0046–0049, 0060; trust boundary and control evidence |
| AUDIT p.12 §09 | Existing firms, API-first firms and independent group channel share the same controls | 0042–0045; no privileged assurance access model |
Appendix F — Threat and verification catalogue
| Threat | Prevent/detect | Required evidence |
|---|---|---|
| Watcher mutates source or ledger | Separate identities; explicit deny; no credentials/egress | IAM/API/storage negative tests, 0001/0007 |
| Forged human triage/confirmation | Server identity resolution and payload-bound authorization | Spoof/replay/stale-version tests, 0006/0031/0049 |
| Cross-client RAG/cache leakage | Pre/post filtering, E-C-O/grant keyed caches and current access | Adversarial tenant-pair tests, 0013/0015 |
| Poisoned/withdrawn requirement | Trusted admission/currentness, not caller flags | Authority-gate fixtures, 0014/0032 |
| Hidden person surveillance | Subject eligibility, cohort/differencing limits, output/context review | Proxy-person red-team cases, 0005/0039 |
| Prompt injection/exfiltration | Data-only context, closed tools, authorized evidence resolution | Malicious documents and SSRF tests, 0048 |
| Alert laundering via suppression | Human decision, expiry, audit visibility, continued monitoring | Suppression expiry/change tests, 0026–0027 |
| Lost events/false completeness | Source reconciliation, outcome partitions and denominator checks | Dropped-event/full-scan tests, 0020–0021/0059 |
| Replayed/duplicated commands | Hash-bound idempotency, unique constraints, lease fences | Concurrent retry/crash tests, 0050 |
| Silent model/policy substitution | Exact execution pins and current gateway controls | Model fallback and policy-race tests, 0010–0011 |
| Tampered history or missing anchors | Immutable revisions, chained events, durable outbox, verified receipts | Integrity/crash/restore tests, 0023/0046 |
| Preparer self-assurance | Client-period/network conflict registry | Affiliate grant denial, 0044 |
Appendix G — Watchtower use cases
This appendix is informative. Counts, sample identifiers and organizations below are illustrative; they are not regulatory facts or deployed records. Each case refers to normative WTWR-REQ rules and inherits all permission, coverage and provenance constraints.
G.1 Regulatory change → supplier due-diligence remediation
- Trigger: Pergamum Pulse registers an effective new requirement version.
- Governed context: exact admitted requirements, adopted supplier policy, DD procedure and applicable supplier attributes.
- Observed population: 47 supplier organizations; 12 have a demonstrated evidence gap.
- Tier: deterministic completeness/evidence checks, supplemented by explicitly graded document-support Observers if required.
- Detection and finding: “12 supplier files no longer satisfy the current due-diligence evidence requirement,” limited to verified rules and covered population.
- Consequence graph: requirement → adopted clause → procedure/control → 47 suppliers → 12 gaps → affected calculations/disclosures where known.
- Prepared remediation: the broker requests FOGE drafts for each affected supplier through PREP/FOGE-REC. Jurisdiction, industry, commodities, relationship, existing evidence and prior answers determine the delta. One supplier may need six fields, another a certificate, another only attestation. Complete Data Needs persist even when interactions are empty.
- Human confirmation: review individual drafts or the explicit “Send all 12” package; revalidate exact recipients, authority and evidence at send time.
- Operative workflow: the owning form service confirms required definitions and dispatches only the still-necessary requests. Watchtower sends nothing.
- Audit: requirement/package versions, supplier population/coverage, gate receipts, form draft hashes, human confirmation, item-level send/retry receipts and later rechecks.
- Rules: WTWR-REQ-0001, WTWR-REQ-0020–0022, WTWR-REQ-0030–0036.
G.2 Procurement contract conflicts with adopted policy
- Trigger: a contract snapshot is saved or scanned.
- Context: exact adopted procurement clause and registered obligation, with the contract snapshot version.
- Population: authorized contracts in scope.
- Tier: Tier 2 for semantic conflict; Tier 1 only for explicit machine-evaluable constraints.
- Detection: an Observer identifies language apparently inconsistent with the adopted policy and cites both passages.
- Consequence graph: contract → procurement control → policy/obligation → affected supplier relationship.
- Finding: graded potential conflict, never a legal opinion.
- Prepared remediation: suggested compliant wording as a separate proposal, retaining original and proposed text.
- Human confirmation: reviewer triages; authorized contract owner separately approves any amendment.
- Operative workflow: existing document/contract process applies the confirmed change.
- Audit: source snapshots, call record, quoted locators, proposal delta and confirmation.
- Rules: WTWR-REQ-0004, WTWR-REQ-0022, WTWR-REQ-0031, WTWR-REQ-0035–0036, WTWR-REQ-0048.
G.3 Collection deadline and completeness failure
- Trigger: scheduled calendar check.
- Context: exact collection obligation, owner, expected entity/site population and deadline.
- Population: required reporting sites, with independently enumerated source totals.
- Tier: Tier 1.
- Detection: due date passed and qualifying submissions are absent for a known subset.
- Consequence graph: collection obligation → missing site data → affected validation/calculation → disclosure.
- Finding: bounded missed/completeness predicate with covered and missing counts.
- Prepared remediation: collection task/form drafts for the missing scope; a revised deadline may be proposed but never applied.
- Human confirmation: responsible owner reviews and separately authorizes task issue or reschedule.
- Operative workflow: collection/FOGE calendar services.
- Audit: frozen clock/deadline, denominator, submissions and exclusions, routing and confirmed task references.
- Rules: WTWR-REQ-0003, WTWR-REQ-0019–0021, WTWR-REQ-0029–0031.
G.4 Policy acknowledgment and competence
- Trigger: substantive policy adoption or scheduled coverage review.
- Context: adopted version, reviewed change classification, acknowledgment population and distinct required training module.
- Population: control/unit aggregates, not evaluated employees.
- Tier: Tier 1 coverage checks.
- Detection: acknowledgment or competence coverage is below its governed target.
- Consequence graph: obligation → policy/control → unit coverage → training requirement.
- Finding: organizational control coverage gap.
- Prepared remediation: optional training-assignment proposal where justified.
- Human confirmation: required only for new assignments/amendments; existing tasks remain in their owning workflows.
- Operative workflow: policy and Academy/provider services. The current user sees relevant policy/change summary/training links, while completed users see “Your requirements are complete” without repeated action prompts.
- Audit: aggregate derivation, exact versions, separate completion evidence, proposal/confirmation lineage and access controls.
- Rules: WTWR-REQ-0005, WTWR-REQ-0026–0028, WTWR-REQ-0037–0040.
G.5 Transaction misclassification
- Trigger: imported transactions or changed supplier profile.
- Context: exact governed classification rule and reporting period.
- Population: 14 illustrative transactions classified as professional services.
- Tier: Tier 2 where descriptions suggest freight; deterministic downstream impact preview remains a separate calculation.
- Detection: descriptions and supplier evidence appear inconsistent with the classification.
- Consequence graph: transactions → classification → Scope 3 calculation → disclosure, with method/factor versions pinned.
- Finding: likely misclassification with calibrated confidence and potential freight understatement if confirmed.
- Prepared remediation: classification correction proposal or proposed rule change.
- Human confirmation: finding disposition followed by separate correction/rule approval.
- Operative workflow: existing classification/calculation services.
- Audit: original values, AI execution, grounded rationale, confirmed deltas and recomputation lineage.
- Rules: WTWR-REQ-0004, WTWR-REQ-0022–0024, WTWR-REQ-0031, WTWR-REQ-0035–0036, WTWR-REQ-0041.
G.6 Evidence deterioration
- Trigger: certificate expiry, source deletion, changed digest or failed evidence-link resolution.
- Context: exact evidence validity requirement and retention/access policy.
- Population: evidence-linked suppliers, controls and calculations.
- Tier: Tier 1 for expiry/integrity; Tier 2 only for content sufficiency.
- Detection: a previously usable evidence item expires or fails its governed check.
- Consequence graph: evidence → supplier/control → supported values/calculations/disclosures.
- Finding: precise expiry or unresolvable-link fact; a revoked viewer grant is an access limitation, not proof the evidence itself ceased to exist.
- Prepared remediation: replacement-evidence request through FOGE where appropriate.
- Human confirmation: owner reviews and authorizes the request.
- Operative workflow: evidence collection service.
- Audit: old/new integrity state, rule/version, authorization distinction, coverage and replacement lineage.
- Rules: WTWR-REQ-0003–0004, WTWR-REQ-0021–0022, WTWR-REQ-0030–0032, WTWR-REQ-0047.
G.7 Document “Scan Now”
- Trigger: user presses Scan Now in a supported Word/document adapter.
- Context: authorized current document snapshot and exact applicable TCCP.
- Population: that snapshot and selected watcher pack.
- Tier: policy-dependent mixture, separately labeled.
- Detection: evaluate mandatory clauses, policy conflicts and referenced-version issues only where governed checks exist.
- Consequence graph: document passage → clause/requirement → relevant contract/report/control.
- Finding: each result displays its tier, source locator, covered scope and limitations.
- Prepared remediation: suggested wording or missing-evidence proposal.
- Human confirmation: user reviews; document modification occurs only through the separately authorized owning workflow.
- Operative workflow: existing document editing/approval.
- Audit: snapshot hash, user scan request, adapter grant/version, selected checks, coverage and AI execution. No keystrokes or behavioral metrics are captured.
- Rules: WTWR-REQ-0017–0018, WTWR-REQ-0020–0022, WTWR-REQ-0031, WTWR-REQ-0048.
G.8 Regulatory change → policy/procedure propagation
- Trigger: registered requirement supersession.
- Context: exact old/new authority, client adoption history and clause mappings.
- Population: affected clients determined by authorized canonical applicability, then tenant-scoped dependent controls.
- Tier: Tier 1 graph/change checks; Tier 2 drafting/semantic observations remain separate.
- Detection: adopted clauses/procedures require review.
- Consequence graph: requirement → policies → procedures → forms → training → operational populations.
- Finding: current regulatory baseline differs from the relevant adopted policy/control chain.
- Prepared remediation: policy/procedure/form/training revisions with explicit dependencies.
- Human confirmation: professional review and client re-adoption in their owning services; substantive change triggers the existing acknowledgment workflow.
- Operative workflow: no automatic adoption or training assignment.
- Audit: before/after graph, affected population, revision proposals, reviewed classification, adoption and acknowledgment versions.
- Rules: WTWR-REQ-0014–0016, WTWR-REQ-0030–0031, WTWR-REQ-0035, WTWR-REQ-0037–0039.
G.9 Continuous assurance
- Trigger: independent auditor requests a reporting-period verification job.
- Context: approved provider, client appointment, conflict-free network and scoped snapshot/rolling grant.
- Population: all authorized monitoring units and findings for the engagement, including suppressions and failed checks.
- Tier: exact Sentinel re-performance and recorded Observer verification remain distinct.
- Detection: verify run scope, source totals, baseline lineage, event history, decisions, evidence integrity and linked operative corrections.
- Consequence graph: observation → finding → human decision → proposal → confirmed object → downstream reported result.
- Finding/exception: missing lineage, recomputation drift, incomplete coverage or unverified AI history becomes an audit exception.
- Prepared remediation: client-side proposal only under separate client authority; auditor cannot change client records.
- Human confirmation: professional exception review and signed opinion remain outside Watchtower.
- Operative workflow: assurance engagement process.
- Audit: all grant calls, pages, replay profiles/results and practitioner decisions.
- Rules: WTWR-REQ-0041–0047, WTWR-REQ-0060.
G.10 Organization-wide reconciliation
- Trigger: initial connection, periodic review, major watcher/configuration change or authorized full scan.
- Context: pinned configuration, applicability, source watermarks and full-scan population selector.
- Population: independently enumerated eligible work objects, partitioned with a sealed root manifest. Tier: every applicable Sentinel/Observer version with distinct outcome accounting.
- Detection: compare the reconciled population with prior delta monitoring and locate missed events, changed baselines and unresolved findings.
- Consequence graph: discrepancy → affected source/control → dependent findings/calculations.
- Finding: newly evidenced gaps create grounded findings; monitoring gaps remain explicit coverage exceptions.
- Prepared remediation: proposal drafts where sufficient authority/evidence exists.
- Human confirmation: no automatic closure of prior findings; reviewers resolve or reopen with fresh evidence.
- Operative workflow: ordinary confirmation services.
- Audit: root/child manifests, source totals, counts, missed-event recovery, deduplication and linked predecessor runs.
- Rules: WTWR-REQ-0019–0025, WTWR-REQ-0050–0052, WTWR-REQ-0059.