Architecture

§3NormativeDraft 2.3Latest draft

Tools never pass files to each other. Each speaks to one core through an adapter, and every crossing between layers is a typed UMP object guarded by a gate.¶

Evidence flows up from raw deliveries to planners; drafts flow down and become official only when a named person approves them.¶

Who uses the evidence

Evidence flows up

Drafts flow down; a named person approves

One adapter per tool

Where evidence comes from

Models

Experiments and data

Tools never pass files to each other. Each one speaks to a single core through an adapter. Every crossing is a typed UMP object, and a gate checks it on the way through.

Models and tests keep working as they do today. The core keeps the meaning attached to every number: which question it answers, how sure it is, where it came from and how far it can be trusted.

The core does not fit models and does not make decisions. Machines draft; named people approve.

Figure 3.1 One core between the tools that make evidence and the people who use it. Click a tool, the core or a user of the evidence to see which typed objects cross at that point and which gates check them. Models and tests send evidence up through adapters; plans and drafts come back down, and only a named person makes them official.

Objects that move between layers¶

Object	Holds	Section
`estimand`¶	Seven-field identity of what a number means	5
`dataset`¶	Labelled dims with policies, roles, units, fingerprint, extraction rating	6
`transform_step`¶	Step type, settings, learned state, who, why, before or after results	6
`model`¶	Tier, capabilities, representation, dependence declaration, valid dates, audit level	7, 8
`test_plan`, `test_result`¶	Pre-registered design; result with range, checks, admissibility class, use-by date	9
`calibration`¶	Tests used, route, mapping, excision window, PSIS diagnostics, conflict decision	10
`scenario`¶	Plan, endpoint revision and view, results with range, fallback step, stale flag	12
`decision_record`¶	Question, options, evidence, recommendation, approver, realised outcome	12
`gate_result`¶	Policy version, artifact version, outcome (pass, fall back, route, warn or stop), fallback applied, evidence, reviewer	15
`evidence_card`¶	Read-only stakeholder view: estimand, range, trust, freshness, used-by	17
`log_entry`¶	Merkle leaf for any sealed record, with key version and anchor	18

modeling-api plays two parts. It is the engine that fits and serves our own models, and its contract package (mapi_spec) is the template for UMP’s contract package (ump_spec), lifted only from its Apache-2.0 SDK side.¶