Automation and Deployment

Automation and Deployment

This page helps locate the authoritative workflow, distinguish a validation result from a deployment, and check the published evidence. The versioned PolicyWatcher operations guide contains the full procedure.

Workflow map

Workflow	Trigger	What it establishes
Validate and deploy GitHub Pages	Pull requests and pushes to main	Linux and Windows validation; only a push to main publishes Pages
Sync PolicyWatcher signals and deploy PALO	Configured at minute 17 of every UTC hour; manual dispatch	Complete snapshot validation, source-review ageing, build and Pages deployment; alerts remain visible
Monitor PALO Knowledge Reader	Configured at minutes 7, 22, 37 and 52 UTC; manual dispatch	Public health, OAuth metadata and anonymous-denial probes; no publication
Publish signed PALO Knowledge Reader	Explicit manual release with tag and approval reference	Separate signed image release procedure

Configured schedules are not proof that a run started or delivered. Inspect the actual run timestamp, commit and job results.

Publication boundary

The Pages workflows publish to the GitHub Pages site. They do not deploy the separately hosted PALO website or the signed Knowledge Reader service. A merged pull request, a successful build and a successful deployment are distinct records.

A normal push build uses the committed offline-safe signal baseline. To verify the freshest signal delivery after a release, finish the main-branch deployment and then run and verify the signal sync. Both publication workflows share a concurrency group, so manually starting one while the other is running can cancel the earlier run.

Read errors and warnings

• A failed sync-build with skipped deploy means no new artifact was published by that run. Inspect the failed step.
• A successful deploy followed by failed alert means a safe artifact was published with an actionable transport or signal alert.
• A skipped deployment in a pull-request run is expected; publication occurs after merge in the push run.
• A review-due warning refers to overdue framework source review. It does not mean PolicyWatcher transport failed, and healthy transport does not renew that source review.
• A cancelled run must be followed to the newer run that superseded it.

Source review handling

npm run sources:age transitions expired current sources to review-due. It preserves their verification dates, checks the existing semantic and Knowledge Reader releases before writing, and updates the affected digests. It does not fetch or substantively review the sources, remove validation gates, or replace a signed Reader image. A source requires accountable review before being marked current again.

See source review instructions and the 6 October maintenance verification.

Verify delivery

1. Open the relevant Actions run and confirm its commit.
2. Inspect build or sync-build, then the actual deploy job and any alert job.
3. Read the published PolicyWatcher registry: check transport state, completion, timestamps and alerts.
4. Read the published framework source registry: review-due sources remain visible.
5. Keep the run URL and artifact identity with the review record. A passing workflow does not establish legal applicability, source interpretation, independent assurance or production authorization.

For local builds and the full P0 gate, follow Getting Started.