Publication Review / Stacked Chain #88 - #100

News Signal Repoint

Two dead CAMEO event-count signals retired in favour of one signal counting Haiku-classified disruption articles per locode. Part 13 of the stack, and the only PR in the chain that moves forecast numbers.

pull_request#100
stack_position13 of #88..#100
tracker#87
files_changed91
hardening+15 commits
PUBLICATION APPROVED
A

What This PR Changes

Every other PR in the stack #88 through #100 is structural. This one is the single change that alters the numbers a forecast produces: the news evidence channel stops counting CAMEO events and starts counting disruption articles classified by Haiku, attributed per locode over a trailing 7-day window.

01 / removed

Two dead CAMEO signals

Both signals were producing no usable evidence. They are removed from the signal set rather than left inert, so nothing downstream can read a stale channel.

cameo_event_count_7d cameo_severity_high_count_7d
02 / added

news_disruption_count_7d

Counts Haiku-classified disruption articles per locode over the trailing 7 days, then scores that count as a z-score against its rolling baseline.

news_disruption_count_7d LR 2.5 threshold_z 2.0
03 / guarded

Correlated-family guard

The new signal joins the news_port_state family alongside the stronger port state peer. When both fire, only the strongest member reaches the posterior; the loser is suppressed and the suppression is recorded.

family news_port_state port_state_disruption LR 4.0
91
files changed
13 / 13
position in stack #88..#100
+15
publication-hardening commits
1 of 13
stack PRs that move forecast numbers

A publication-hardening pass added eleven commits on top of the repoint itself. Each one exists to make the change safe to publish against a live production database rather than to change what the model computes.

Hardening 01
Fail-closed scoring gate
Scoring refuses to run unless the gate says it may; the closed state is the default.
Hardening 02
Immutable schema publication
Schema version records are written once and never rewritten; drift aborts before any write.
Hardening 03
Contract documentation reconciled
Documented contracts brought back into exact agreement with the shipped code.
Hardening 04
Executable database preflight
Runnable check of the production target, in shell and against the Modal-injected value.
Hardening 05
Focused CI
A narrowed matrix that runs the tests this change actually puts at risk.
B

Signal Flow: Article to Posterior

Five stages, left to right within each lane and top to bottom between them. Dashed blue edges are reads from a store; solid green edges carry a derived value forward; the dashed red edge is the correlated-family suppression. Hover any node to isolate the edges it touches and reveal their labels.

data read derived value family suppression hover a node to trace its edges
stage 01source
article documents
news articles
port-routes-news articles in the trailing 7-day window
NEW
Haiku classifier
disruption_classification
only articles classified as disruption continue
stage 02attribution cascade
step 1 / primary
resolved_locodes
use the locodes already resolved on the article
step 2 / fallback
scraper query mapping
map the scraper query that found the article to a locode
step 3 / fallback
title keywords
last resort: match locode keywords in the article title
aggregate
7-day count
disruption articles per locode over trailing 7 days
stage 03scoring
standardise
z-score
count measured against its rolling baseline
evidence
LR table entry
fires at threshold_z 2.0, contributes LR 2.5
stage 04correlated family
family peer
port_state_disruption
stronger member of the family at LR 4.0
guard
news_port_state
at most one member of the family reaches the posterior
SUPPRESSED
outcome
news suppressed
peer wins; the news LR is dropped, not multiplied in
stage 05posterior
update
Bayesian update
surviving likelihood ratios applied to the prior
combine
ensemble
Bayesian posterior combined into the ensemble output
persist
prediction ledger
prediction record plus its Bayesian audit fields
stores read
articles
port-routes-news
articles carrying the Haiku classification
signal registry
LR table
LR, threshold_z and family membership per signal
history
rolling baseline
the distribution the 7-day count is standardised against
audit
suppression record
each dropped family member is recorded on the prediction
C

HMM Observation Contract

Changing the signal set changes the shape of the observation the hidden Markov model consumes. The vector narrows from five dimensions to three, and the order of those three is canonical: inference reads positionally, so the order is part of the contract rather than a convention.

Observation vector

Width is fixed by the signal set. Every consumer of the model must agree on both the width and the order.
5before 3after
[0] news_disruption_count_7d z-score
[1] insurance_severity_score_7d raw weighted severity
[2] port_occupancy_anomaly z-score
Position [1] is deliberately not standardised: it enters as a raw weighted severity while its neighbours enter as z-scores.

States and matrix shapes

Six hidden states. The matrices below are drawn for structure only - the probabilities themselves live in configuration and are not reproduced here.
0DORMANT 1RHETORIC 2POSTURING 3CRISIS 4CONFLICT 5DE_ESCALATION
transition 6 x 6
emissions 6 x 3
initial 6
Highlighted cells on the transition grid are the self-transition diagonal. The emissions grid is 6 x 3 because the observation vector is now three wide.
runtime

Pure NumPy inference

Inference runs on NumPy alone. No sampler, no probabilistic-programming runtime, and no model fitting inside the scoring loop.

configuration

One strict hmm_config document

Exactly one hmm_config document in forecasting.mappings holds the contract. It is strict: shapes and canonical order must match or the model does not load.

mutation

Forward-only exact-preimage cutover

That document is replaced only through the cutover CLI, which requires the exact expected preimage and moves in one direction. There is no in-place edit and no reverse step.

D

Cutover Safety Ladder

Publishing the repoint against a live database is an ordered ladder of thirteen steps. The order is load-bearing: every step either establishes a guarantee the next step depends on, or proves that a guarantee already established still holds.

01

Capture schedule state

Record the current scheduling configuration before touching anything, so the end state can be compared against a known starting point.

02

Stop the app

Take the running application down so that nothing is scoring while the underlying contract is being changed.

03

Install and verify the unique gate index

The gate depends on a uniqueness guarantee. The index is installed and then verified, not assumed.

04

Initialize and activate the scoring gate

The gate is created and switched on. From this point scoring is fail-closed: it runs only if the gate explicitly permits it.

05

Deploy with schedules off

The new code is deployed with scheduled execution disabled, so deployment itself cannot start a scoring run.

06

Prove scoring is blocked

Blocking is demonstrated from both surfaces: the CLI refuses to score, and the API answers with 503.

07

Verify the remaining indexes

Every index the new query patterns rely on is confirmed present before any of them are exercised.

08

Reconcile signal watches

Watches are brought in line with the new signal set, so nothing is still watching a signal that no longer exists.

09

Publish schemas immutably

Schema version records are published under the write-once rules detailed in section E: insert when absent, no-op on exact match, abort on drift.

10

Run the bounded HMM cutover

The single hmm_config document is replaced through the forward-only, exact-preimage CLI. Bounded means it changes that one document and nothing else.

11

Write-free deployed canary

The deployed build is exercised without writing. Authorization for the canary is revocable and bound to both the database identity and the cutover ID, so it cannot be replayed elsewhere or later.

12

Restore the deployment while the gate is still active

Normal deployment configuration is restored first, with the gate still closed. Restoring and unblocking are two separate steps, never one.

13

Deactivate the gate

Only now is scoring allowed to resume. The gate is the last thing to move, not the first.

failure mode

Forward-only: a failed cutover stays stopped

There is no rollback path down the ladder. If any step fails, the scoring gate stays active and schedules stay off - the system holds in the blocked state rather than resuming with a half-applied contract.

E

Immutable Schema Publication

Schema version records are published, never updated. The publisher is defined by what it does in each of four situations, and two of those four are refusals. Drift is detected before anything is written, so a mismatched record can never be silently overwritten by a deploy.

Situation at publish timePublisher actionOutcome
No record exists for this (collection, version) insert The record is created. This is the only path that writes.
A record exists and matches exactly no-op Nothing is written. Republishing the same contract is safe and repeatable.
A record exists and differs (drift) fail Publication fails before any write. The stored contract is never mutated to match the code.
Duplicate-key race: a concurrent writer won the insert reread and compare The winning record is reread and must match exactly; anything else fails. The race cannot smuggle in a different contract.
v1predictions

The v1 record is restored rather than dropped, so the historical shape stays describable after the repoint.

carries the historical polymarket_comparison shape
v2predictions

The v2 record documents the retirement of v1 and adds the flat Bayesian audit fields the correlated-family guard writes.

model_outputs.bayesian.effective_lr_count model_outputs.bayesian.correlation_suppressions
F

Review & Verification

Sixteen review outcomes across the eight-role team protocol and four independent lanes, plus the test evidence. Filter by outcome class, then click any card to expand its lens, what was examined, and the resulting position.

outcome Clear Accepted risk Out of scope
G

Verdict

PUBLICATION
APPROVED2 FINAL-SHA FIXES

Publication approved — two final-SHA fixes applied

The repoint carries one behavioural change and a hardening pass built to publish it safely. Both remaining defects were corrected at the final SHA rather than deferred.

fix 1 · flat v2 Bayesian audit paths fix 2 · Modal-injected database preflight