PolicyWatcherPublic evidence laboratory
Experimental programme

Engineering notebook / 01

Engine 6Preview

A clearer path from source to evidence.

Engine 6 Preview is being developed and tested to make policy retrieval, comparison and validation more traceable. This page opens the design for inspection.

Architecture

Three questions guide the experiment.

01

Is this the complete policy?

Check the document identity, required sections, language and final passage against a reviewed source contract.

02

What supports this conclusion?

Keep frozen captures, exact quotations and a separate verification step connected to each proposed change.

03

Can the work recover safely?

Save tasks, attempts and checkpoints so interruption does not erase progress or publish a change twice.

01 / Architecture

Evidence moves through explicit boundaries.

Official sources enter a private working area. A public record is created only after the required checks succeed. Retrieval, AI analysis and delivery have separate responsibilities.

Architecture: official sources enter a persistent queue, retrieval and source checks. Frozen evidence feeds comparison, analysis and verification. Review holds uncertain cases. An atomic commit creates public evidence, followed by a separate notification queue.
Official inputs, private working evidence and the publication boundary.
Read the diagram as text
  1. Official source

    Direct HTTP, HTTP/2 and a configured browser renderer supply bounded retrieval paths. Archive captures do not attest current live availability.

  2. Private work and evidence

    Durable tasks, per-origin backoff, frozen artifacts and checkpoints preserve the retrieval and reasoning trail. Observation and publication keep separate policy state.

  3. Publication boundary

    Complete, supported changes may commit automatically at lower impact. High impact requires review; missing or uncertain evidence remains held.

  4. Public record and delivery

    The baseline, version, change record and queued notification event commit together. Delivery happens later and checks subscription preferences again.

02 / Decision flow

An HTTP success is the start of the checks.

The change path requires two fresh captures in distinct runs, separated by at least one hour and no more than seven days. A 304 response can revalidate a stored representation; it cannot confirm a new change.

Decision flow: check the source contract and captured document; reject incomplete evidence. An unchanged baseline records a verified check. A candidate change needs two independent captures, a comparable baseline, clause comparison, exact claims and verification. Uncertainty stays held; high impact needs review; supported lower impact may publish.
Green: verified outcomes. Amber: waiting or review.
  1. 1

    Check the source

    Missing contract, source drift, incomplete content or uncertain language → hold and record the reason.

  2. 2

    Compare with the baseline

    Unchanged content → record a verified check. Missing or incompatible baseline → review before comparison.

  3. 3

    Confirm the candidate

    A matching fresh capture in a different run confirms the candidate. A retry or a conditional 304 response does not count as a second capture.

  4. 4

    Explain every changed block

    The analyst must cover the complete delta with exact old/new quotations. A separate verifier assesses every claim and both language versions.

  5. 5

    Apply the publication gate

    Unsupported or uncertain claims → hold. Verified high impact → human review. Complete supported lower-impact changes → atomic commit when publication is enabled.

Human approval does not waive missing evidence. Source or extraction-baseline repairs have their own review path. A purely presentational extraction change does not become a provider policy-change alert.

03 / Entity relationships

The relationships behind a recorded change.

This is a conceptual map of the implemented preview schema. A solid line is an explicit database foreign key; dashed lines are application-managed references, including identifiers in checkpoints and evidence payloads.

Entity map showing EngineRun and EngineTask connected by an explicit one-to-many foreign key. Dashed logical references connect tasks, attempts, artifacts, source contracts, per-mode policy state, reviews, cache, origin scheduling, public changes and outbox events.
Solid: database foreign keys. Dashed: application references.

Scroll horizontally to read every column. Keyboard: focus the table area and use the arrow keys.

The relationships behind a recorded change.
EntityWhat it recordsRelationship / identity
EngineRun → EngineTaskA requested run and its resumable work.Explicit runId foreign key; one run has many tasks.
EngineAttemptEach claimed task stage and its outcome.Logical taskId; attempt history is separate from the current task.
EngineArtifactFrozen captured or derived evidence with integrity checks.Content-addressed ID; logical references from checkpoints and evidence payloads.
EngineSourceContractReviewed expectations for one source document.policyId identity; logical relationship to Policy.
EnginePolicyStateDue time, last verified state and candidate confirmation.Composite identity (policyId, mode); observe and publish are separate.
EngineOrigin · EngineHttpCachePer-origin pacing and eligible conditional representations.Origin / cache-key identities; cache logically references an artifact.
EngineReviewFrozen evidence, reason, decision and review history.Unique taskId/evidenceKey; logical policy, artifact and change references.
Policy · PolicyChange · EngineOutboxPublic baseline, committed change and deferred delivery.PolicyChange → Policy is an existing FK; outbox changeId is an application reference.

04 / Validation

What the evidence currently establishes.

Recorded local verification, 31 October 2026. These results are a starting point for qualification, not a production accuracy score.

Automated regression suite

1,369 passed · 14 skipped

Synthetic fixtures do not measure retrieval quality on the live catalogue.

Engine-specific tests

43 passed, included in the full suite

A 500-record scheduling test is not 500 successful Internet retrievals.

Build and static checks

Production build and TypeScript passed; lint had no errors

15 pre-existing web lint warnings remain; no independent dynamic security audit is claimed.

Administrative workflow

Approval and cancellation verified against an isolated database

One clearly labelled synthetic policy; no subscriber notifications.

Model-assisted code review

Gemini 4 High and GLM-5.3 Max reviewed frozen candidates

Review is not execution or certification. Subsequent fixes were tested locally.

Qualification pending

The next test is the real catalogue.

Before live activation, qualification needs an annotated corpus and at least three complete daily windows. The target is up to 500 policies per day; reliability and coverage take priority.

  • Source identity and completeness
  • False change alerts and unsupported claims
  • Retrieval coverage, retries and latency
  • Model tokens and cost per changed document
  • Evidence growth, backup and restore

OCR for scanned PDFs, general PDF structure recovery, automatic source-contract onboarding and automatic evidence pruning are outside this preview. Ambiguous documents remain in review.