# The Harness — intro, where the docs are, and how we develop **Authority:** canonical engineering entrypoint and document map. **Maturity:** connected capabilities are live in the tree or exported owner compositions; the estate separately labels unconnected code and production-host gaps. Precise Gateway 0.2.1 is observed running through Boombox on Cloud Run with GCS Product state, a synthetic source, and live Trust validation. Its optional customer dataset handle is not bound; the live discovery command returns the authenticated upload/bucket continuation. Start here. This explains **what the harness is**, **where all the documentation lives**, **what the skill file is**, and — most importantly — **the methodology and point of view** for anyone (human or coding agent) building here. ## What the harness is Precise is a research and product shop. Its differentiated methods, evidence standards, experiments, decision systems, workflows, and customer judgment are the source of the products. The harness is how that work becomes executable, comparable, qualifiable, and portable without giving away its meaning to a UI, transport, database, or host. The harness is the Precise operating substrate—not a Polymarket-specific system. **Every connected capability is a harness** = a pure **core** + a named **CLI/API contract** over it + a self-**`describe`** (composes into a tree index) + continuous **`evals`** + the honesty **`floors`**. UIs and agents are *clients* of harnesses. A capability reachable in a UI but absent from a harness core is a **defect**. The repository also contains substantial code that is not connected yet; the estate index must show that gap instead of making an absent tree node look like an absent capability. Code: `harness/` (framework: `defineHarness`, `defineComponent`, `serveHarness`, `policy`, `floors`, `outcome`, `tenant`, `eval-store`, `deploy`). ## Product law at every client boundary The [Precise Product Laws](../../PRODUCT.md#precise-product-laws) bind every product backed by the harness and every UI or agent that projects its results. The core may retain exact internal terms such as `settlement`, `seal`, `floor`, and `harness`; the customer projection must translate them. Do not rename a real core to solve a copy problem, and do not leak core vocabulary to avoid designing the projection. Every product slice therefore starts from a documented customer outcome and a persona grounded in cited primary records. Its useful-path fixture or eval proves the current contribution, the next useful change, and predicted value with confidence or bands when those meanings exist. Its refusal path distinguishes a genuine evidence limit from internal compute progress. Offline verification and host progress may remain available to an authorized operator, but a customer UI or agent never replaces already-available product value with that sequencing. Method evidence stays reachable through a separate, openable projection. Customer copy and agent responses use the customer's language, define a Call through its five customer fields when present, label synthetic demos once, and report confidence plus realized learning instead of a right/wrong tally. The canonical core retains six granular accountability fields; the customer projection groups `happened` and `contributed` as “what happened and what contributed” without dropping either record. Surface-specific acceptance checks live in `FRONTEND-STANDARD.md`; `PRODUCT.md` remains the single normative statement of the laws. ## Where the documentation lives (the map) | Doc | What | |-|-| | **`PRODUCT.md`** (repo root) | canonical Precise Product Laws for every product, surface, and agent | | **`HARNESS.md`** (this) | intro + methodology + doc map — **start here** | | **`BUILDING-PRECISE-APPS.md`** | tactical TDD path for a new app/service or progressive migration of an existing one | | **`PRODUCT-COMPILER.md`** | in-development path from a customer technical deep dive, connected facts, and goal to a saved composition, preview, cassette, or application | | **`AGENT-ABLATION-RUNBOOK.md`** | domain-neutral experiment lifecycle: frozen evidence, controls, ablations, courts, receipts, and promotion | | **`PRECISE-DECISION-LEARNING-CAPABILITY-PLAN.md`** | canonical Precise Harness master plan: Decision Learning, Product cells, named reads/BFF, Surface eval, Boombox operation, and capability travel | | **`DEVELOPING-HARNESSES.md`** | **how to develop**: code a harness, ablate, capture-for-training, polyglot (TS controls Python) | | **`ATTACHING-HARNESS-SERVICES.md`** | attach a large project lazily and expose the same tree as a bounded HTTP service | | **`KONSTANT-BOOMBOX-ASKS-CONSOLIDATED.md`** | one human entry point for what Precise needs from Boombox and the first proof sequence | | **`BOOMBOX-PLATFORM-CONTRACT.md`** | short map of all 26 host ports, ownership boundaries, overrides, and current implementation status | | **`BOOMBOX-DEPLOY-LIFECYCLE-REQUIREMENTS.md`** | designed application plan, apply, inspect, rollback, retirement, and regional-placement contract | | **`BOOMBOX-WORKLOAD-CONTROL.md`** | built Precise worker and plan binding, live generic Boombox host/provider, and the remaining assignment-bound control join | | **`PRECISE-ESTATE-BACKPLANE.md`** | whole-repo/service inventory, native telemetry, Boombox host boundary, and attachment order | | **`RUNBOOK.md`** (repo root) | how to run/extend/deploy the harness | | **`.claude/skills/precise-harness/SKILL.md`** | canonical coding-agent skill / POV for Claude and Codex (see below) | | **`CONNECTIONS.md`** | honest status: what actually runs real `packages/*` code vs stub | | **`PLAN.md`** (repo root) | the build order | | **`pipeline.html`** | the whole system, diagrammed — the hand-off for Matt | | **`MATH.md`** | the real estimators, cited | | **`ADVOCATE-LOOP.md`** | the offline/online scale architecture | | **`BENCHMARK.md`** | the worklist product + the identifiability backtest | | **`TENANCY.md`** | the network-of-networks data model | | **`PARTNER-RIGHTS.md`** | data/model/learning rights (only aggregate crosses) | | **`OPERATIONS.md`** | infra survey + the operator agent + settlement | | **`FINDINGS.md`** / **`DECISIONS-AND-QUESTIONS.md`** | the adversarial findings + how each is closed | | **`KONSTANT-QUESTIONS.md`** / **`KONSTANT-ALIGNMENT.md`** | Boombox deployment questions + the answers/alignment | | **`docs/research/workflow-outputs/`** | every multi-agent analysis, raw | The ordered list is served from the repository CLI: ```bash cd harness npm run precise -- docs npm run precise -- skill ``` The `docs` response includes `readInOrder`. Follow that array for a fresh developer handoff; use its generated estate commands and `CONNECTIONS.md` for current status instead of treating `NOW.md`, `HANDOFF.md`, or an old commit message as live truth. ## What the skill file is `.claude/skills/precise-harness/SKILL.md` is the canonical in-repo **coding-agent skill** — frontmatter (`name`, `description`) plus a body that tells Claude or Codex *how to work here*: discover via `describe`, wrap real cores, respect the non-negotiable floors, and use the methodology below. Root `AGENTS.md` and `CLAUDE.md` make this file authoritative if a cached tool-local copy drifts. ## How discovery works Use runtime and estate truth before broad source search: 1. `cd harness && npm run precise -- describe` for connected commands, floors, evals, and state. 2. `cd harness && npm run precise -- estate coverage` plus `estate drift` for repository and deployment maturity. 3. `ccc search "concept"` for semantic discovery across source and docs; narrow with `--path` or `--lang`. 4. `ccc grep ''` for structural discovery. 5. `rg` for exact symbols, call sites, and final verification. The shared CocoIndex scope lives in `.cocoindex_code/settings.yml`; generated index state is local. Run `ccc index` after meaningful changes. CocoIndex helps a developer find the right seam; it is not runtime, deployment, ownership, or proof authority. ## Generic start, durable local continuity, and worked examples The default tree contains only dependency-light capabilities intended for every Precise process. `product-build` keeps one named user, desired outcome, repository authority, and ordered developer-attempt record recoverable across coding sessions. It mints only its own local session and developer-attempt IDs. Runtime Product sessions, deployments, logical runs, run attempts, Calls, and other issuer-owned identities remain opaque bindings. Its current proof pair binds one passed useful eval and one refusal that actually fired; it does not yet dereference those evidence bytes and grants no promotion or host authority. It is an internal continuity tool, not an approval ritual or a prerequisite for a developer's first useful change. The ordinary start path is inspect the Product contract, run one useful eval, build the app, and ask through the attached Project Need when the platform seam is unclear. Domain-shaped applications are explicit lazy attachments. Campaign Improvement, its media read, Next-Dollar caller, publication adapter, Board BFF, and MCP route load together only after `precise init campaign-improvement ...`. They are a closed synthetic worked example that a builder may run, clone, strip, or ignore. They are not the generic Product shape, a default assignment, or the source of the standalone Decision Learning node. A new Product may start directly from the generic primitives without importing any of them. ## Always-on Product delivery Precise Product applications consume one owner-operated, tenant-bound Gateway. Most product callers use Product commands or named workflows. Method discovery and direct math calls remain available to workflow authors and advanced integrators through the same service. The first exported Product composition is `@precise/harness/always-on-precise-gateway`: ```text app / UI / agent │ Product view · recommend · record result · history ▼ tenant-bound Precise Gateway ├─ named outcome ingestion → verified Outcome Observation ├─ real Mondrian calibrator + exact descriptive contribution ├─ pre-granted weight target → Learning Decision update ├─ Decision Learning closure/v2 + retained verification └─ Precise publication adapter → neutral binding-receipt port ``` The developer has two tracks. Build a Product application against this client, or add reusable Product behavior behind a port plus its conformance runner. The developer does not choose or reimplement the default math, operate cloud custody, author tenant identity, pass a Product-learning grant, or invent a host `run_id`. The owner composition mounts those concerns once. An override replaces an implementation behind the same port; it does not fork Product semantics. The outcome-ingestion port deliberately sends fixture and customer records through the same verifier and record shape. The current Connect-shaped implementation includes one bounded named BigQuery reader with an injected query client. Trust validation adds a separate host-projected GCS data-handle seam: an authenticated Product-account setup may back it with either a managed upload location or a customer-connected bucket prefix. The Gateway accepts only that credential-free binding, then requires an immutable snapshot and digest before method execution; caller payloads never select a bucket or tenant. No customer handle or intake UI is deployed. The retained Product-learning authority is a rights label on the corpus. The default setup materializes its grant and weight target together, so the integrity refusal is not a builder-facing gate. The standing composition mounts the optional Campaign Improvement BFF as one complete proof: named campaign read → measured coalition construction → recommendation and Call → retained pre-action close context → mature outcome → verified closure → update → next recommendation. The next recommendation resolves and applies the exact learned-state bytes retained for it; it does not merely cite an update. Local tests prove the useful path, exact retry, restart, tenant isolation, state-pinning races, learned-state incompatibility, the rights-label refusal, and history with empirical stated-band coverage plus the latest exact contribution/update. That history is the accepted learned-state successor chain. It is not a second index of every closed episode. Two updates that race from one consumed state do not create competing heads: one advances and the other refuses `consumed-state-stale`. The refused decision closure remains independently inspectable; a new recommendation must consume the accepted head. Chain order comes from exact state bindings, never timestamps or content-hash sorting. The local file adapter serializes successors inside one standing process; it does not claim safe shared-directory writes from multiple processes. The same standing composition accepts complete injected GCS custody. Calls, Attestations, closures, primaries, binding receipts, Product-learning authority, decision-to-state pins, and track-record history stay immutable; only bounded Product heads use generation CAS. A fresh-process test reopens the completed result and proves the next recommendation applies the learned state written by the first process. The exact bucket+prefix pair selects this composition through ambient ADC/workload identity; partial configuration refuses. GCS is storage, not the Gateway process host. Build the host artifact from `harness/`: ```bash npm run build:gateway-bundle npm run test:gateway-bundle ``` For the Boombox Cloud Run lane, package those exact bundle bytes with the checked-in minimal image recipe: ```bash docker buildx build --platform linux/amd64 \ -f Dockerfile.standing-gateway \ -t \ --push . ``` The image contains only `dist/server.mjs`, runs as numeric non-root user `65532:65532`, and carries no credentials. The pushed digest—not a mutable tag— enters the application descriptor and Boombox apply plan. The build emits a byte-deterministic unsigned app-bundle and ConnectorBundle under `harness/dist/standing-precise-gateway-bundle/`, prints the exact digest, and never reads signer material. The extracted-artifact test starts the bundled entrypoint, probes `/health` and `/harness`, completes one cycle, restarts, and reattaches the same Product history. After the Boombox operator signs the ConnectorBundle, the public `standing-precise-gateway-application` builder accepts only content-addressed artifact, signed-manifest, and attestation refs whose artifact digests agree. No MCP path or external intent is declared. The 0.2.1 staging revision observed on 2026-09-02 proves Boombox Cloud Run placement, host identity, GCS application-state custody for the synthetic composition, Trust validation HTTP parity, `report`, `band_basis`, and an armed event-booking door. It had 20 transitions and 17 input schemas; no real producer outcome was observed. It predates the current neutral `math` child, default continuation workflows, and Campaign workflow reader. A customer dataset handle, Product-account upload, dedicated Product-bucket connection, snapshot worker, end-user authentication, hosted analyst, and neutral receipt publication remain unhosted work. Precise exposes injected composition-root ports for payload-free host operation recording and for an exact, strictly shaped application-revision reference. The published runtime adapter must source it from the active host injection. The same direct, Harness, and HTTP resolution path seals a distinct create-once deployment-linked evaluation locally and reattaches it unchanged after restart; it never invents a Boombox Run. The public Boombox patch is published, consumed, and live for operation records. In the current package-pinned scope, the joined evaluation is sealed locally and verifiable offline; Precise does not deliver it to Boombox. Crossfade and Arranger are optional lineage when they actually ran; Decision Learning depends on neither. ## Gateway math and continuing workflows The current default and standing compositions mount a neutral `math` child and a Precise-owned `workflow` child. This is separate from the older Campaign-specific Gateway commands above. `math methods` lists the methods the exact process can run, including runtime schemas, implementation-bound versions, and scaling modes. `math run` returns the literal terminal result; `result`, `status`, and `cancel` address the same tenant-bound run. The Gateway does not apply Product rungs, claim limits, or a Product-policy catalog. Authentication, tenant binding, byte integrity, resource limits, and external-action authority remain mechanical boundaries. The Precise workflow surface exposes: - `understand-the-book` — contribution, pair interaction, grouped contribution, fitted value, capture, and regime views; - `find-the-next-move` — fitted response, marginal frontier, price, and portfolio analyses; - `design-the-test` — holdout power, information value, and transition analysis; - `measure-and-learn` — rerun calibration, contribution, interaction, value, and transition methods as outcomes arrive; and - a focused one-cycle graph over caller-selected mounted methods. These are computational recipes. They are not complete Campaign Improvement, Trust Portal, factory, trading, or other Product journeys. A Product adapter must compile its retained records into method inputs and interpret the returned results. Only additive-fit→predict and gradient-fit→analyze currently pass fit state between steps; the other named steps are parallel analyses. The Product connects sources, reuses an accepted field map, takes the measured goal, and selects or composes the fitting workflows behind the scenes. Data changes rerun the fitting work while the last complete answer stays visible. Technical names and method comparisons belong in why/what-changed drill-down. The Product projector returns the finest supported controllable primitives, such as creative × channel × audience × placement, with measured contribution, uncertainty, interactions, current size, and marginal value so a primitive can load into a proposed move. It keeps unsupported dimensions missing and never turns measured decomposition into an unsupported causal claim. Workflow storage keeps the initial input, exact accepted outcomes, completed and pending cycles, complete step inputs and outputs, diagnostics, and raw Gateway references. New cycles replay the original input plus accumulated outcome patches and rerun the methods. They do not silently install a prior model or posterior as the current primitive state. A primitive that needs online state must serialize it or carry a content-addressed state reference in the next input. Decision Learning remains the Product record for a recommendation or Call, actual exposure, mature outcome, score, and lesson. A workflow cycle proves what math ran; it does not prove that a customer action occurred or grant permission to perform one. Current operating limits are explicit: active individual math calls are not a restartable detached queue; a retained continuation workflow needs its exact definition and method versions to resume; each settled change writes a new, complete immutable revision containing the accumulated history, so retained bytes grow with steps and cycles; and source-head lineage remains in the separate outcome event/store. The full surface and commands are in [`GATEWAY-PRIMITIVES-AND-MATH.md`](GATEWAY-PRIMITIVES-AND-MATH.md) and [`GATEWAY-WORKFLOW-BUILD.md`](GATEWAY-WORKFLOW-BUILD.md). ## Decision Learning episode and optional Call opening The internal learning unit is a **Decision Learning episode**, not an isolated Call or a chain of mutable result objects. The customer product is the workflow that connects data, explains the current state, recommends or applies a change, measures the outcome, and improves the next recommendation. Independently authoritative, create-only Product records carry each meaning. A create-only closure binds their exact `{ref, digest}` pairs and verifier facts; the episode is a read-only projection recomputed from that closure and those primaries. An episode begins with a measured baseline observation and distinct typed pre-decision analyses. A route may select a proposed change to weights, allocation, policy, or another controllable input. Only when that route forms a measurable, forecast-bearing bet does a Call freeze `known`, `chosen`, and `predicted`. Analysis-only work, route refusals, and recommendations that cannot form a scoreable bet do not fabricate a Call. ```text baseline Outcome Observation + distinct typed analyses -> decision brief and route -> optional Call for a measurable forecast-bearing change -> actual Action Exposure, deferral, or no-action state when applicable -> verified mature Outcome Observation -> Forecast Score when the frozen forecast and exact exposure make it scoreable -> distinct typed post-action analyses -> Learning Decision or explicit none under named Product-learning authority -> create-only closure binds exact primary refs + verifier facts + lineage -> recompute the Decision Learning episode -> next weights or policy and the next episode ``` The typed analysis records keep four questions distinct: 1. **Outcome decomposition:** how an observed total is allocated across declared parts under a named value function, denominator, interaction, and additivity contract, without implying causality. 2. **Driver claim:** what the historical evidence supports at its exact descriptive, predictive, or causal ceiling. 3. **Effect estimate:** what changing a controllable lever is expected to do relative to a declared comparator. 4. **Process contribution:** how a method, capability, evidence source, human, or agent changed the recommendation, refusal, confidence, cost, or latency. Forecast Score separately evaluates the frozen prediction against the exact Action Exposure and verified observation. Learning Decision alone states whether that evidence may update a future weight, policy, model, route, or qualification. Each primary retains its own evidence ceiling and authority; none silently substitutes for another. The history is append-only. It retains immutable references to definitions, model and release, baseline observation and analyses, recommendation, optional Call, actual Action Exposure, mature observation, Forecast Score, post-action analyses, Learning Decision, closure, uncertainty, refusal, and any later correction. A correction appends an immediate-predecessor-bound primary restatement and successor closure. It never resets or overwrites a primary, closure, or prior episode view. Authorized customer evidence can therefore train better Precise models later without detaching the lesson from the exact history that earned it. Raw data stays in its declared custody. Konstant receives only the shared facts the customer grants for capability routing and network learning. The closure proves which exact primaries passed which verifier; it does not create their observation, analysis, score, judgment, or learning meaning. The episode is recomputed rather than stored as a second ledger or derivation record. The **Decision Learning Board** renders the complete episode. A **Call Sheet** is its focused bet view when a Call exists. Both are surfaces over the customer workflow and its internal records; neither is the product itself. The commands below operate the Call-opening boundary and the initial Call-bound closure inside that larger episode. They also expose the independent Call Attestation boundary. The default node wraps the canonical `packages/research-core/src/call.*`, `packages/research-core/src/call-attestation.*`, and `packages/research-core/src/decision-learning-episode.*` implementations; it is not a second Call or episode model. ```bash cd harness npm run precise -- decision-learning describe npm run precise -- decision-learning eval npm run precise -- decision-learning call-inspect \ --tenant_path precise/acme/media \ --decision_id campaign-42 npm run precise -- decision-learning episode-inspect \ --tenant_path precise/acme/media \ --decision_id campaign-42 ``` The operational commands are `call-open`, `call-inspect`, `verify-call-opening`, `call-attest`, `verify-call-attestation`, `episode-close`, `episode-inspect`, `verify-episode`, `episode-close-v2`, `episode-inspect-v2`, and `verify-episode-v2`. `@precise/harness/decision-learning` exports the typed in-process and HTTP clients, runtime codecs, local stores, Call-Attestation verifier conformance helper, and closure-verification issuer conformance helper. Direct core, leaf harness, full tree, HTTP tree route, and SDK client return the same content-addressed opening, refs-only closure, and recomputed episode. Exact retries reuse retained bytes; changed content returns a stable conflict code; a sibling tenant fires `cross-tenant-target`. The default composition injects local create-only Call-opening, Call-Attestation, closure, and primary journals under the ignored harness results directory and reattaches across process restarts. Its Call-Attestation verifier is explicitly non-cryptographic reference assurance: it proves the port, retry, and transport contract, not production identity. A production composition injects the same `CallOpeningStore`, `CallAttestationStore`, closure store, primary store, approved attestation verifier, and durable idempotent semantic-verification issuer ports with their custody, recovery, and availability contracts. The local journals prove independent Precise product behavior. Boombox is the canonical operated network adapter when the Product selects that operating road for Precise-managed production, customer infrastructure, or downstream distribution. Host availability never changes Product meaning. A missing reusable Boombox primitive becomes a typed requirement while a bounded adapter keeps product delivery moving. The opening is content-addressed, not signed. A separate create-only `precise.call-attestation/v1` may bind its exact retained opening hash to tenant, principal, acting-for mandate, Product, capability, release, signer, signature, and a verifier Receipt; it grants no action or learning authority. The Call's opened projection reports `happened`, `contributed`, and `taught` as null and grants no scoring, analysis, reliability, execution, activation, promotion, or learning authority. The initial closure slice accepts independently verified Action Exposure and mature Outcome Observation records and derives Forecast Score. Closure/v1 retains explicit analysis and Learning Decision `none` dispositions. Closure/v2 may additionally retain one exact-additive descriptive post-action outcome decomposition and one Learning Decision update whose target class is granted by the retained Product rights label. Both write one refs-only closure and recompute the episode on read. Retained verification reloads custody and checks existing receipts and rights without minting a new receipt or time. No-Call identity, successor closure, the other identified analysis kinds, non-null Claim Judgment, and correction semantics extend the same protocol in later core increments. The canonical construction and model-learning sequence is `PRECISE-DECISION-LEARNING-CAPABILITY-PLAN.md`. ## Product publication and the neutral binding primitive Every decision-bearing BFF, Board, Call Sheet, agent, and MCP surface consumes an exact Product result through a **Precise-owned publication adapter**. Decision Learning and its Product caller make the only judgment. The publication adapter owns the mapping from Product records to opaque `{name, ref, digest}` bindings. It does not re-price, re-route, re-score, or rejudge the Product result. Beneath that adapter is a domain-neutral binding-receipt port. It knows only a tenant and namespace scope, a caller-owned create-once key, canonically ordered opaque bindings, and receipt identity. Product, Call, forecast, route, refusal, calibration, or learning meaning is prohibited in the primitive. ```text Product core → Decision Learning records → Precise publication adapter → thin BFF | neutral binding-receipt port / \ Precise file custody hosted Boombox custody (local only) (not connected) Hosted durable work → Boombox workload control → host-minted run_id + lifecycle Receipts ``` The exact `@konstantdotcloud/boombox` release pinned in `harness/package.json` exports the public `boombox.binding-receipt.v1` port and conformance runner. The Precise create-only file adapter passes that suite, reuses exact retries, refuses changed content and tampered files, preserves structured tenant sub-scopes, and reattaches in a fresh process. This is public-contract conformance plus local custody, not a hosted Boombox service or live tenant bind. The receipt is run-less, mints no application or workload `run_id`, and grants no execution or effect authority. Workload run identity and lifecycle Receipts remain separate Boombox workload-control records. ```bash cd harness npm run precise -- media-next-dollar-publication describe npm run precise -- media-next-dollar-publication eval ``` The first publication adapter binds the exact media Next-Dollar recommendation or refusal. The Campaign Improvement BFF consumes its client and projects only the opaque binding receipt reference alongside the Product result. The older bespoke policy-to-price-to-verdict HTTP demo retained in `examples/legacy/media-gateway` is quarantined historical Product material, not the canonical package export, supported example, or primitive contract; it must not become an alternate Product route. ## The methodology & POV (how we develop) 1. **Harness the ablation *seam*, not every function.** A component earns a harness iff it's a **swappable implementation of a stable contract with ≥2 variants** OR **it enforces a floor** — else it's plumbing, keep it plain code (`defineComponent` lints this). This is how we *ablate within a system*: swap a variant, re-run the invariants, compare (`component.ablate()`; e.g. Shapley exact|cc|additive). This is implementation conformance. A result-changing claim also follows `AGENT-ABLATION-RUNBOOK.md`: frozen evidence, controls, untouched confirmation, separate courts, and an explicit promotion or null receipt. 2. **Import the real code; never copy it.** For a single canonical implementation (the neutral receipt contract → `@konstantdotcloud/boombox/receipts`), import and wrap + add an eval proving the wrap against the real contract. A re-implementation is a silent drift hole. For multi-variant seams, import the pieces *and* expose them as variants so you can ablate. 3. **Polyglot behind one contract.** `describe`/`eval`/`` over the `{ok}` envelope is the polyglot boundary — a harness can be TS/Python/Go/Rust, composed through `bridge-python` or exposed through `serveHarness`. A remote-child client is not implemented yet; do not advertise one. Language follows the workload; don't rewrite for uniformity. 4. **Keep the capability tree separate from tenant topology.** The harness tree composes executable capabilities. The versioned topology separately relates organizations, tenants, deployments, policies, and evidence handles. A bound tenant path such as `precise/omg/adidas-eu` scopes an invocation, storage, and telemetry, but graph adjacency never grants command authority (`TENANCY.md`, `tenant-topology.ts`). 5. **Only sealed aggregate arithmetic crosses a boundary.** Never raw/user-level records — enforced by `tenantScoped` (it rejects any result declaring a raw `_crossing`); the live-egress path that emits crossings is new-dev (`GLOSS-CLOSURE.md`). 6. **The floors are non-negotiable.** They're machine-checked (`floors.ts`/`policy.ts`/`outcome.ts`); a claim that can't clear one isn't honest yet. Run `node harness/scripts/floor-lint.mjs ` before publish. 7. **Findings live in code, not docs.** A finding that only lives in a `.md` rots; encode it as a floor + a test (`finding-floors.ts`). Docs point at the code, not the reverse. The through-line: **make every meaningful seam a harness** — discoverable, evaluable, ablatable, floored — in whatever language fits, isolated by tenant path, honest by construction. Polymarket is one opt-in proof that this substrate travels outside media; it does not define the substrate or load into the default media tree. ## Evidence-bound research programs `defineComponent().ablate()` answers whether implementations survive their own invariant fixtures. A claim about real data uses the stronger experiment path: ```ts import { createResearchProgramHarness } from "@precise/harness"; ``` The caller freezes one question, a complete recipe for every alternative, an immutable evidence pointer, split/economics rules, controls, and required courts. The adapter opens one `openVerified` evidence handle whose verification and materialization are the same source view, retains unavailable cases, and applies one typed missingness policy. `hard-zero` sends the full eligible population to every recipe and keeps unavailable confirmation cases in support; `identified-subpopulation` requires a sealed eligibility-rule hash; `withhold-estimand` stops before evaluation when anything is unavailable. The generic kernel owns `freeze`, `run_once`, `verify`, `compare`, v2 canonical sealing, control leakage, required-floor execution, court gating, and the null/promotion receipt. Separate legacy `verifyEvidence` and `materialize` calls cannot clear the evidence gate. `changedSeams` is derived from the recipes; an adapter cannot merely claim it changed one thing. The workload reference host now proves durable file and injected generation-CAS GCS execution with claims, fencing, retries, checkpoints, terminal idempotency, and reattachment. Boombox Plan057 separately proves authenticated generic admission, triggers, durable control state, customer-owned Cloud Run Jobs/GCS, controller replacement, read-only attachment, terminal custody, and one signed fleet projection. The public `@konstantdotcloud/boombox` package exposes both provider-free authoring/planning and the authenticated workload-control client; runtime authority still comes from the tenant-authorized host. The remaining proof is one full Precise assignment envelope traversing that client and host in a Precise-owned immutable worker image. The experiment core has no activation command and every receipt carries `orderAuthority: "none"`. Decision-facing research uses the `decision-program` child beneath that same default `research` node. Its scientific spine is: ```text DecisionEvidenceMap/v2 -> primary DecisionResearchRoundPlan/v2 -> independent AuditDesignReceipt/v1 -> ResearchExperimentIntent/v1 -> ResearchRoundAssignment/v1 -> terminal and court receipts ├─ Decision-Impact Episode opening/closing └─ ContextualNominationReceipt/v1 -> ContextualConfirmationRound/v1 -> confirmation ResearchAssignmentBasis/v1 with outer receipt binding scope-matched qualification + independent targets -> DecisionProposalSet/v1 ``` The map separates a durable scientific definition, an evidence-bound instance, and a known-at planning offer. The primary plan uses vector budgets and never selects its own audit. The independent audit samples only after the hold frame is frozen. Assignment joins one exact primary run or sampled audit row to the experiment, policy semantics, release, desired placement, physical plan, and workload. The episode retains the full denominator and records which targets may or may not train a later planner; a selected-only outcome cannot train the selection policy. Contextual nomination reconciles the exact primary and sampled-audit outcomes and requires distinct, selector-withheld fresh support with the same definition, predicate, decision-contract, evidence-class, and live time scope. It grants nomination-only authority or a sealed refusal. The row-local proposal compiler does not consume a nomination directly. The contextual confirmation round first replays it, projects only nominated definitions onto the exact fresh support, retains the complete discovery denominator, and schedules every runnable nomination or refuses the whole confirmation plan. That outer receipt is still planning-only. The row-local proposal compiler separately accounts for every declared independent target with `move|adapt|fork|pin|ask|suspend|refuse`. `move`, `adapt`, and `fork` require an already-issued, scope-matched promotion-equivalent verification. `ask` carries an interim pin-or-suspend policy plus nomination-only or promotion-equivalent qualification. `pin` preserves the exact incumbent; `suspend` explicitly stops it. It refuses coupled portfolio decisions and does not produce an Arranger `DecisionPlan`. The confirmation map is not assignment authority by itself. A confirmation row must pass through `freezeConfirmationResearchAssignmentBasis()` with the exact outer confirmation receipt and replay context. The basis binds the nomination, discovery map and plan, fresh support and scope, confirmation map, expected plan, and candidate definition. The complete chain enters the physical evidence refs; a substituted or missing outer receipt refuses. The current contextual controls bind terminal, court, fresh-support, and qualification receipt references and replay their declared scope and time. They do not dereference and independently verify pinned source bytes. Production composition must inject those source verifiers before the references can carry scientific or promotion-equivalent authority. This scientific spine is orthogonal to the host spine: ```text host admission -> logical run -> attempt -> checkpoint -> terminal host receipt ``` They join by immutable hashes. A Precise assignment is desired work, not host admission. Boombox must separately accept or refuse its exact assignment, workload, placement, tenant, topology, budget, and residency bindings. The default decision-program surface is research-control-only and exposes only `freeze-*`, `verify-*`, `project-*`, and bounded planning commands. It has no run, admit, dispatch, execute, promote, activate, persistence, signer, or order verb. `createAdmittedResearchExperimentWorkloadBridge()` proves the first join across the two spines. It contextually verifies one experiment assignment, its physical plan and workload, the exact no-order research adapter, and one task binding. Only after an injected host verifier accepts an already-issued admission receipt does it expose a workload handler that calls the real `run_once` and stored `verify` commands. The bridge cannot issue admission, create compute, dispatch, or widen authority. It refuses multi-task assignments until typed stage adapters exist. `createBoomboxResearchWorkloadBinding()` proves the adjacent planning join. It uses the exact consumer-locked `@konstantdotcloud/boombox` public API to derive a descriptor, target, and local non-authoritative plan from the verified Precise program. Tenant, program digest, runner, implementation, placement, and binding drift refuse. This command does not mint a token or call apply/invoke. Real-scale experiments also freeze a `precise.research-physical-plan/v1` before launch. This is the physical counterpart to the scientific spec: it binds the immutable release and evidence refs, a separate non-nested mutable scratch resource, the materialized stage DAG, a content-addressed engine-resource config plus host resource and billing ceilings, create-only publication, the complete denominator, and one common opportunity key across every variant. Host-managed scratch requires a positive free-space floor; provider-managed scratch records that no local floor is observable with an explicit `null`. When a host process writes more than its primary stage scratch—for example, a nested source verifier reopening its own sealed scratch—the stage declares every exact file URI in `host_writable_resources`. `verifyResearchHostWritePathBinding()` requires the systemd `ReadWritePaths` set to match those resources exactly. Missing paths and undeclared extra write authority both refuse before dispatch. Missing rows remain unavailable instead of disappearing, ranking happens before economic expansion, and information value remains separate from execution value. The default `research` node exposes `freeze-physical-plan` and `verify-physical-plan`; a domain workload binds the resulting `plan_hash` into its evidence refs. `verify-physical-workload-binding` proves the workload and plan share tenant, logical run, implementation, and the exact plan hash before dispatch. The contract does not launch compute or choose a provider. ### What the large Polymarket run changed in the general harness Polymarket supplied the failure pressure; these are now domain-neutral contracts and apply equally to media work: | Observed failure | Generic Precise rule | Media equivalent | | --- | --- | --- | | A row-expanded recipe grid became physically intractable before it became scientifically useful. | Materialize a wide common spine once, then derive recipe scores and exact capacity prefixes in bounded later stages. Bind the stage DAG in the physical plan. | Join delivery, cost, identity, and outcome facts once before comparing allocation policies. | | A process had ample host memory but DuckDB still used a hidden 512 MB engine limit and spilled beside a read-only release. | Seal engine settings separately from host ceilings; keep mutable scratch outside immutable releases; record whether scratch is host- or provider-managed. | A scoring or attribution worker cannot silently change heap, concurrency, spill, or temp storage between campaign variants. | | A downstream verifier reopened an upstream sealed scratch path that systemd had left read-only. | Bind every host-writable resource in the physical plan and verify the exact service write-path set before dispatch; a nested verifier path is a runtime dependency, not an implicit implementation detail. | A media audit reopening a prior identity or attribution spool cannot fail after launch because its hidden temp path was omitted, nor can the service gain an undeclared broad write mount. | | An evidence image hashed an allowlisted source set but installed a monorepo-wide dependency lock, so unrelated research changed the release identity and broadened the executable graph. | Freeze one dependency-minimal release graph: the source allowlist, locked runtime dependencies, staged files, and entrypoint imports must agree. Recompute that closure before immutable control publication. | A campaign evidence collector should not install every warehouse, model, chain, or activation dependency—or require a new campaign seal when unrelated Precise research changes. | | Candidate caps and model-specific filtering could make a weak recipe appear better by changing who was measured. | `source_cap` and `candidate_cap` are explicit `null`; every variant left-joins to one frozen opportunity key and retains unavailable cases. | Every bidder, segment, creative, or allocation policy is judged on the same eligible inventory and measurement failures stay visible. | | A missing source hour or failed materialization was easy to serialize as an empty result, making “not observed” look like “observed zero.” | Unavailable work is a typed, sealed artifact. Its population status is `unavailable` and unknowable counts stay `null`; only a verified empty population may report zero. | A late delivery file or failed identity join cannot be mistaken for a campaign with zero impressions, conversions, or eligible users. | | One process could collect evidence, bless a model, score decisions, and allocate capital merely because it had all four functions in memory. | Collection, qualification, scoring, and allocation are separate capabilities with separate receipts and authority. Collection continues safely when later authorities are absent; no payload can grant a host a missing verifier. | A media collector may keep landing delivery facts while a measurement policy is under review, but it cannot turn those facts into a budget move without the qualified scorer and activation gate. | | A predictive markout and an executable trade were easy to conflate. | Information, execution, capacity, and contribution are separate courts. Attribution explains measured value; it cannot manufacture it. | Predicted lift is not delivered savings; fees, auction mechanics, reach, pacing, and budget capacity need independent evidence. | | A delayed action was trained against a different time interval, and a target-level key hid that target choice occurred inside the policy. | Freeze `precise.research-policy-semantics/v1`; bind its hash into the physical plan; require exact score/action targets for direct calibration and make the target-selection boundary part of the opportunity unit. | A media policy cannot train on immediate campaign lift, act after a pacing delay, or select a creative inside the policy while claiming creative-level support without saying so explicitly. | | A selective planner saw only the outcomes it chose to run and could teach itself that its omissions were harmless. | Freeze the full decision denominator, sample an independent hold-frame audit with known inclusion probabilities, and close an assignment-rooted episode with explicit training eligibility. Selected-only primary results cannot train selection. | An allocation advocate cannot learn that ignored campaigns or segments were low value merely because it never measured them. | | Long cloud jobs outlived terminals and agent sessions. | Physical stages publish create-only outputs and a CAS terminal pointer; the workload protocol owns claims, leases, checkpoints, retries, and reattachment. | A multi-day media backfill or model grid resumes from evidence instead of depending on the developer session that launched it. | | An 18-month actor pipeline crossed US landing, EU acceptance/materialization, and US cleanup, so “the job succeeded” was too coarse to authorize the next action. | Freeze the full partition universe; bind each lane to its physical plan and workload; admit only the matching partition's exact upstream terminal receipt; declare placement per lane; make acceptance and destructive cleanup separate authorities. Worker concurrency never changes the frozen denominator. | A media ingestion, identity join, attribution run, and activation export can cross data planes without treating file presence, a scheduler success, or a small worker pool as proof that every customer partition is complete or safe to purge. | This is why the Polymarket adapter remains optional while the policy-semantics, physical-plan, workload, staged-provider, court, and receipt contracts live in the default Precise research surface. The actor-history build also removed one repeated implementation detail from domain adapters. `publishImmutableCurrent()` now provides the dependency-light create-only-content plus compare-and-set-current algorithm in `@precise/research-core/publication`; the actor pipeline consumes that shared primitive. It reuses an identical concurrent result and refuses a different result for the same logical pointer. One useful gap remains explicit. The cross-lane partition graph, execution placement/residency, and acceptance-to-cleanup authority split are currently a proved Polymarket composition, not yet a domain-neutral schema in the default tree. That is the next extraction point for media backfills and model grids; until it has independent media conformance coverage, the Harness must not call it a universal production orchestrator. The default tree mounts this protocol as the domain-neutral `research` node. Run `npm run precise -- research` from `harness/` to discover its contracts. It can freeze specs, verify specs and experiment/stage receipts, and compare compatible receipts. Its `decision-program` child adds the v2 map, primary plan, cold exact coverage reference, independent audit, intent, assignment, episode, contextual nomination and confirmation planning, and row-local proposal contracts without adding a domain runner. The default node deliberately has no `run_once` or activation command: an application earns a runnable surface only by injecting a real adapter, floor runtime, and durable host through `createResearchProgramHarness({ adapter, floorRuntime, host })`. Every floor named by the frozen spec is executed. A missing evaluator is `unknown`; an omitted, throwing, or unreachable evaluator is `unexecuted`; `unknown`, `unexecuted`, and `fired` all refuse the winner. The optional `media-decision-research` attachment is the first non-Poly client of the v2 map and exact cold planner. It imports the canonical historical campaign roster and next-dollar frontier, retains one missing frontier as a blocked row, and assigns no performance-derived priority. This proves the core is domain-neutral; live customer evidence and a controlled media run remain separate work. The default tree also exposes `precise attribution attribute` as the domain-neutral finite-game math surface. A domain adapter first measures a complete coalition value table on its frozen evidence; this node then runs canonical exact Shapley/interactions/Owen (through 16 players) or seeded sampled complementary contribution (17–20). Exact output may award attribution credit. Sampled output is research-only and explicitly lacks a confidence interval. Neither output is a strategy selector or promotion court by itself. External services can inject a long-lived worker through `createFiniteAttributionCore` without importing a domain. ## Typed research providers **Maturity:** REAL as a dependency-light composition core and contract fixture. `createResearchProgramHarness()` persists the verified stage-receipt bodies in the injected `ResultStore` and binds their ordered hashes into the research ledger pointer. Production durability still depends on the injected host store; the separate generic workload core supplies tested claims, leases, fencing, retries, checkpoints, file/GCS persistence, and worker reattachment. A real generic Boombox registry/Cloud Run/GCS provider now exists and the Precise composition root binds its public plan, but no exact assignment-live invocation or media evidence adapter is implied. `createStagedResearchAdapter()` is the common seam between a frozen experiment and domain math. It composes five injected Precise-owned providers: ```text verified evidence source -> feature assembly -> recipe evaluation -> execution evidence -> portfolio/capacity -> contribution attribution -> ExperimentDomainAdapter ``` The policy provider receives `{id, recipe}` rather than `baseline|challenger|negative-control`; experiment roles stay in the generic court and control logic. Every batch must return exactly one row for every input row. A provider may mark a formerly available row unavailable with a reason, but it cannot drop or revive missing evidence. Portfolio support must equal the confirmation denominator selected by the typed `failurePolicy`; prose cannot change that denominator. The runner freezes one `ResearchRunContext` from the experiment, evidence, adapter, implementation hash, and seed, and passes that same frozen context to every provider and cache. Each stage produces a content-addressed `precise.research-stage-receipt/v1`. The receipt binds the experiment and spec hashes, run context, evidence manifest and `knownAt`, provider implementation, alternative recipe hash, exact predecessor receipt hashes, input and output populations, and provider output hash. The source itself has a receipt, so the complete source-to-contribution receipt graph is verifiable rather than a bag of self-consistent hashes. Its authority is always `research-only`, with `orderAuthority: "none"`. Exact attribution may retain crediting authority for the attribution numbers only; sampled attribution is research-only and must say that confidence intervals are unavailable. Neither case widens the experiment or permits activation. These receipts are not process-only breadcrumbs. On `run_once`, the research harness verifies the complete receipt DAG, stores it beside the final experiment receipt, and seals their hashes into the ledger pointer. `verify` rejects a missing, changed, spliced, or unbound staged receipt. Stored-run reuse also verifies the receipt semantically against the requested spec, adapter, implementation, floor results, derived winner, receipt DAG, and exact ledger pointer; recomputing a self-hash is not enough. A production host can therefore move the same record to BigQuery, Postgres, or object storage without reinterpreting its meaning. The executable fixture in `harness/test/research-stage-providers.test.ts` is the concrete reference. A domain composition has this shape: ```ts const adapter = createStagedResearchAdapter({ id: "media-allocation/v1", source: campaignEvidenceSource, // verifies one immutable manifest features: campaignFeatureAssembler, // retains every missing source row policy: allocationRecipeEvaluator, // reads alternative.recipe, not its role execution: dspDeliveryEvidence, // observes feasibility; never dispatches portfolio: sharedBudgetCapacity, // emits metric + paired comparison + court contribution: campaignAttribution, // exact or honestly sampled attribution }); const research = createResearchProgramHarness({ name: "media-allocation-research", version: "1.0.0", purpose: "Compare frozen allocation recipes without activation authority.", adapter, floorRuntime: mediaResearchFloors, host, }); ``` The providers and their number-producing methods belong to Precise. Boombox may schedule them, persist their receipts, and run injected workers behind host ports; that operation does not transfer the research semantics or product ownership.