# How it all works Data lands in Product-owned custody with its source, scope, and time meaning attached. The Precise Gateway turns that data into decisions through one served mouth and keeps each decision on the record. A Call is the durable record of five things: what was known, what was chosen, what was predicted at what confidence, what happened and what contributed, and what that taught the Product; the lifecycle is make the Call, score it later, then book the lesson. Mature outcomes score earlier Calls and turn the result into learned state. The loop reruns itself, seals the next graded report, and compounds a track record that later decisions can use. **Authority:** orientation to the current repository and generated estate; [Connections](CONNECTIONS.md) and the commands at the end remain the status authority. **Maturity:** current on 2026-09-02. “In the repository” means checked-in code; “deployed” means an observed running revision. They are not interchangeable. ## The Precise Gateway is the served mouth The current repository projects `precise.gateway-capability/v2`: a neutral catalog of the methods the mounted service offers, their paths, input shapes, mutation flags, and opaque floor and eval references. It does not describe a state machine, assign rungs, or impose Product policy. Reader access can inspect that catalog and `status`; full authenticated callers can invoke the mounted commands. The `math` child exposes `methods`, `run`, `result`, `status`, and `cancel`. The default development tree has 24 domain-neutral methods. Seventeen are dependency-light; seven appear when their release-bound workers are configured. The standing composition therefore serves 17 without worker configuration and all 24 with both worker URLs and immutable release digests. The default `workflow` child exposes `workflows`, `start`, `focus`, `outcome`, and `result`. Precise supplies four continuing workflows: `understand-the-book`, `find-the-next-move`, `design-the-test`, and `measure-and-learn`. They run version-bound methods, retain literal Gateway results, compare useful variants, and append another immutable cycle when an outcome arrives. The customer surface connects data sources, keeps one accepted field map, takes the person's measured goal, and lets the Product select or compose the fitting workflows. The Product reruns them when data changes, keeps the last complete answer visible during the update, and puts method names and comparisons under why/what-changed drill-down. Calls, actions, and outcomes remain Product state. The Product answer must arrive at the finest supported controllable grain, such as creative × channel × audience × placement, rather than as a campaign blob. Each primitive carries measured contribution, uncertainty, interactions, current size, and marginal value so it can load into a proposed move. Missing dimensions stay missing, and measured decomposition is not a causal claim. The repository-local Campaign Improvement `/trust` route is now becoming an operating modeled-example decision view backed by the read-only workflow projection. Its adapter can read the workflow catalog and a retained result, including workflow version, findings, and comparisons. It does not execute a workflow, build Campaign method inputs, or turn raw math into real Campaign Improvement artifacts. This math and continuation code is connected in the repository's default tree and standing composition. It is not deployed. The last staging revision recorded in [Connections](CONNECTIONS.md), `app_rev_4ac0c1d7`, is a 2026-09-02 observation of the older Campaign Improvement service; it does not contain the current `math` or default continuing `workflow` child. ## The learning loop closes one Call and opens the next The checked-in path is: signed event door → find mature Calls → resolve the outcome → learn → rerun the decision → seal a `precise.campaign-report/v1` containing the graded Board and the next Board. A Board is the readable projection of the Call and its state. An outside consumer exercised the loop rather than reading its tests: as reported by the credit-table lane on 2026-09-01, one booked result changed history from zero to one and tightened the sensitivity band from 284,537–384,962 to 333,963–335,536 (primary record: the credit-table lane's GW-1 report, `composer-20260830/.foreman/reports/GW-1.md:80`, with the served payloads retained in its committed dump at that worktree's commit 1f90bdda7 — verified by this session on 2026-09-01). This learning path is repository code. The historically observed staging source is synthetic, and no real producer outcome has exercised the current workflow continuation there. The BigQuery producer that turns campaign panels into mature outcome rows is still unbuilt. ## Capabilities are real at different maturities - **Portfolio Select:** a built lazy library with firing quality, measurement, and diversity floors; no Product caller, deployment, or settled real shadow race. - **Capture tape:** a real local measurement library and append-only recorder with venue-neutral parity fixtures; no Product caller, hosted recorder, cadence, or telemetry. - **Grounded chat:** a default-tree local core used by both Campaign Improvement analysts. One local Doppler-backed smoke completed a real Cloudflare AI Gateway model call. No hosted chat service, production store, production secret delivery, or customer-session proof exists. - **Precise outcome workflows:** the default `workflow` child runs the four named continuing analyses and focused method sets. File and GCS stores retain cycles, exact outcome bytes, completed steps, and raw run references. The code is connected in the repository and not deployed. - **Saved workflow definitions:** a separate hidden lazy harness, selected with `precise init workflow` or its `saved-workflows` alias, saves sealed `precise.workflow/v1` definitions and runs them synchronously. It also reports its harness name as `workflow`, so it collides with the default continuation child's name even though their commands and records are different. It has no deployed mount. - **Self-heal:** three lazy remediation verbs with fake action-port proof and a real deploy-road wrapper; no durable hosted store, uptime subscription, timer, or bound pager. `describe` shows the mounted and optional tree. [Evals Guide](EVALS-GUIDE.md) explains what success and refusal evals prove, with Portfolio Select as the worked example. ## Boombox operates the reusable rails beneath Precise The repository pins Boombox `0.14.10`, whose operation record accepts `usage_atoms`, `run_id`, and `invocation_id`. The standing Gateway operation adapter emits one `verb_call` atom for each command it maps, including the eleven default Product commands and three optional workspace-result commands. The current `math/*` and continuation `workflow/*` paths are not mapped, and the hidden saved-definition runner emits no per-step operation records, so those paths have no operation atoms yet. The boundary rule is short: Precise owns the Product, customer relationship, research method, and meaning; Boombox owns reusable admission, operation, and network seams; typed requests, results, and references cross that boundary, not ownership, raw tenant data, or secrets. ## Each company owns the workflows that give its data meaning Precise owns the four Precise workflows above and the Product adapters that turn their raw math into decisions, reports, and later cycles. Another company can use the same neutral Gateway methods for a factory, logistics system, trading system, or another Product while owning its own workflows and interpretations. The lazy saved-definition harness is an internal/reference runner, not the default outcome-continuation service. Konstant's selection-signal, Arranger, and syncopation capabilities remain separate planned supplier applications on the Boombox capability plane; they are not live Precise capabilities. ## These are the surfaces people can see - **Credit table:** the [live static mock](https://precise-credit-table-mock-ebad447b.surge.sh/) is reachable and exercises a practice loop. It is not the real frontend or a customer release. - **Decisions product:** HEAD still contains the local Campaign Improvement SvelteKit surfaces (UI deprecated). The composition engine was SHELVED unmerged on 2026-09-01 (tag `shelf/composition-layer-20260901`); when a served verb needs one of its cores, the builder imports that core verb-native or writes fresh — nothing converges by merge. - **OMG Pulse:** the Next.js app is on `codex/pulse-ap-7b`, the NestJS service on `codex/spine-sv-4c`, and the Precise spine on `codex/omg-spine-20260830`. All three are local branches, unmerged and undeployed, with product decisions still held by Adam. - **Jordan's start road:** [Build the full Trust Portal package](../../JORDAN-START-HERE.md) is the product-only path a new developer follows: a local, trusted-operator Product first, then the same Product through the hosted Gateway. It contains no development-process content by rule (Adam, 2026-09-01: Jordan gets product only). ## Where to go next Run the current machine-readable inventory from the repository root: ```bash cd harness npm run precise -- describe npm run precise -- estate coverage npm run precise -- estate drift ``` Then use [Evals Guide](EVALS-GUIDE.md) to test claims, [Building Precise Apps](BUILDING-PRECISE-APPS.md) to add or connect a Product, and [Connections](CONNECTIONS.md) for the full maturity ledger.