Bayesian Evidence Update Model

Assumptions

Everything the model believes, stated before the math. If you do not buy one of these, do not buy the output.

1. The prior is the class base rate: the operating share among resolved projects of the same type, shrunk toward 0.5 with a weak prior of effective sample size 8.
2. Update kernels are a versioned contract (bayes-contract-1.0), not fitted per case: milestone met +2 alpha, official confirmation +1, filing progress +0.5, milestone missed +4 beta.
3. Kernels are asymmetric by contract: a missed milestone outweighs a met one, matching the base-rate record that misses are rarer and more informative.
4. Each source contributes at most once - a repeated source is repetition, not corroboration.
5. Client attestation updates a private Case only; it is rejected for public-corpus posteriors with the reason printed.
6. An evidence class with no calibrated kernel is rejected as UNKNOWN-capable, never silently applied.
7. Update order is chronological, then id-stable - and the order is part of the versioned contract.

Derivation

The belief is a Beta distribution over the probability that the project delivers. The prior pseudo-counts come from the class record, shrunk toward 0.5 at ESS 8:

Each accepted evidence item adds its kernel's pseudo-counts. The posterior is the closed-form Beta-binomial update - no sampling, no fitting, no judgment call at run time:

Acceptance is gated before any math runs: client attestations are rejected (private Case only), repeated sources collapse to one contribution, and classes without a calibrated kernel are rejected with the reason printed. Every rejection is listed on the output with its reason.

If no evidence survives the contract, the posterior is UNKNOWN - restating the prior is not an update. Sensitivity to the prior family is printed as the mean shift when the prior's effective sample size is halved with the same kernels:

Identification strategy

Why the estimate supports the claimed meaning - and where the model refuses to claim more than the data carries.

• The update is identified by the contract, not by an analyst: priors, kernels, hierarchy and update order are versioned, so two runs over the same evidence produce the identical posterior - and any change to how evidence moves belief is a version event, not a vibe.
• Source dedupe is the circularity guard: five articles re-reporting one filing are one observation, and the model rejects the echoes by source id rather than counting them as independent confirmation.
• Asymmetric kernels encode the base-rate asymmetry honestly: missed milestones are rarer than met ones, so a miss carries more information and moves the posterior harder (+4 beta vs +2 alpha).
• Rejecting uncalibrated evidence classes is the identification boundary: applying an uncalibrated kernel would be narrative reassessment dressed as updating, so the class is refused and the reason is printed.

Inputs and outputs

Calibration and gate evidence

Validation design

• The contract is validated by determinism and rejection behavior, not by fitted accuracy: kernels are policy, and their calibration is a review question (do the pseudo-counts match the base-rate record) rather than an optimization.

Evidence on record

• Smoke gates at seal (8 m25-specific): repeated source collapses to one contribution; attestation rejected as private-Case-only; uncalibrated class rejected with reason; posterior is the deterministic Beta update; a missed milestone outweighs a met one; sensitivity to prior printed; no surviving evidence yields UNKNOWN posterior rather than the prior restated; determinism and audit row written.

Gates at seal

• smoke: 8 m25 gates incl. determinism + audit row (suite counts at seal per the build agent's seal report)
• sealed at b17b531c on atlas-nl-shock-redesign

Failure modes

The ways this model declines, degrades or goes UNKNOWN - and what it prints when it does.

• No surviving evidence (all items rejected): posterior is UNKNOWN with the reason - the prior restated is never dressed up as an update.
• Evidence class outside the kernel table: rejected as UNKNOWN-capable with the reason printed.
• Project type absent from the record: the prior pool falls back to all projects, and the shrinkage prior keeps the estimate weak and wide.

Sensitivity

• The kernel asymmetry is the dominant behavior: one missed milestone (+4 beta) cancels two met ones (+2 alpha each) - that is the base-rate record encoded, and the page shows it.
• Prior strength (ESS 8 shrinkage) matters most on thin classes; the printed sensitivity quantifies exactly how much the posterior would move under a weaker prior.