stratum atlas
Model DocsDecision
M36

Negotiation Conditions Model

Which conditions to take into the negotiation - each one derived from an observed risk path on the record, never brainstormed.

Assumptions

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

  1. Every condition starts from an observed risk path. A risk path without a record reference, or one not marked observed, is rejected - conditions are never brainstormed.
  2. Every condition is labeled PROPOSED. The output type has no other status; nothing here is an existing term or a market standard, and no downstream render may imply one.
  3. The mapping from risk type to condition category is a fixed table, never improvised arithmetic or prose invention.
  4. One condition per category; duplicate risk paths of the same type collapse.

Derivation

The model is a guarded table lookup, not a generator. Each risk path on the record is first screened: it must carry a record reference, and it must be observed rather than hypothesized. Paths that fail either screen are rejected with their reason printed.

Surviving paths map through a fixed table from risk type to condition category. Supplier concentration maps to step-in and diversification rights; delivery slip to a liquidated damages schedule; regulatory milestone risk to a milestone-evidence condition precedent; shared grid exposure to a curtailment allocation term; counterparty credit to performance security; an unresolved blocking unknown to a condition precedent on resolution; water source and geographic hazard to resource security terms.

A risk type with no structural mapping is rejected with the reason - the table is the whole model, and extending it is a methodology change, not a runtime decision. The output is the set of proposed conditions, one per category, each carrying its risk reference and basis, plus the rejected list with reasons:

where R_obs(s) is the set of observed, referenced risk paths on the subject and map is the fixed table. With no observed risk paths the model returns an empty list and says why - an honest no-basis output, never a set of generic asks.

Identification strategy

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

  • The record reference requirement is the identification: a condition exists only where a concrete, citable risk path exists, so every proposal traces to evidence.
  • The observed-only rule separates measurement from imagination - hypothesized risks produce no conditions, which is what keeps the output an audit artifact rather than a brainstorm.
  • The fixed mapping table removes discretion: the same risk types always produce the same categories, so any disagreement is about the table, stated in the open, never about a one-off judgment.

Inputs and outputs

Reads

Risk paths for the subject
record references with observed flags, assembled upstream from the corpus
Risk type per path
the typed risk register on the record
As-of date
the run frame

Writes

  • proposed conditions: category, risk reference, PROPOSED status, basis - one per category
  • rejected risk paths with the rejection reason for each
  • no_basis: UNKNOWN when there is nothing to propose against, with the reason

Calibration and gate evidence

Validation design

  • There is nothing to calibrate statistically: the model is a fixed mapping with screens, so correctness is contractual (screens and table enforced) rather than estimated.
  • The mapping table itself is reviewed against closed negotiations as those records enter the corpus; changes land as version bumps, not silent edits.

Evidence on record

  • smoke gates cover the three laws: no-reference rejection, observed-only rejection, unmapped-type rejection, one-per-category dedupe, no-basis UNKNOWN, determinism.

Gates at seal

  • smoke: m36 gates incl. the three laws, dedupe, no-basis UNKNOWN, determinism + audit row (suite counts at seal per the build agent's seal report)
  • sealed in the 10W.12 capability wave on atlas-nl-shock-redesign

Failure modes

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

  • A stale or mistyped risk register misroutes conditions - the model inherits the register's typing, so register quality is the control.
  • One-per-category dedupe can hide multiplicity where two distinct paths of one type deserve distinct terms; the printed risk reference shows which path carried the category.

Sensitivity

  • Deterministic under the same inputs: same risk paths, same table, same conditions - byte-identical.

Iron rules

Conditions are never brainstormed: no observed risk path, no condition.

Every condition is PROPOSED - never rendered as an existing term or a market standard.

The mapping table is fixed; unmapped risk types are rejected with reasons, never improvised.

Source and audit

Written from the sealed model source. Every run is recorded - model version, frozen inputs, input hash, timestamp. There is no unrecorded model execution.