# Boombox platform contract for Precise

This is the short version of how Precise develops through Boombox.

Precise is the research and product engine. It owns every Precise product: product strategy, customer relationships, packaging, UX, applications, workflows, domain policy, and vertical integrations. It also creates and owns the differentiated decision logic underneath them: math, models, floors, commands, evals, ablations, evidence meaning, and domain behavior.

Boombox supplies the reusable operating and network primitives those products run on: identity, isolation, persistence, service discovery, deployment, scheduling, secrets, operational telemetry, lifecycle receipts, and capability distribution. This lets Precise concentrate its energy on research, product judgment, and customer delivery while carrying its capabilities into Precise-hosted infrastructure, customer estates, and downstream ecosystems.

This is a development method, not a restriction on Precise. When a Precise product exposes a missing reusable need, Precise defines the typed seam and pulls the capability into the Boombox roadmap. A bounded local adapter may support the product until the shared primitive lands. Precise remains free to run specialized compute and data planes; Boombox keeps the common operating ontology and control plane coherent.

Precise domain cores stay portable by calling typed ports on one `Boombox` object. Provider and vendor adapters enter at the composition root, where local, Precise-hosted, and customer-hosted implementations can change without rewriting the research or product semantics.

```text
Precise core or harness
        |
        | calls bb.<port>
        v
Boombox contract
        |
        +-> default Boombox adapter
        |
        +-> stronger service-owned adapter, when the workload needs one
```

The interface is in `harness/src/boombox-seams.ts`. The network and discovery model is in `harness/src/tenant-topology.ts`.

The **Precise publication adapter** is a Product seam above these ports, not a
Boombox judgment API. Decision Learning computes one exact Product result; the
adapter maps its Product-owned `{ref, digest}` records into opaque bindings; the
thin BFF and Product surfaces consume the unchanged Product result. The adapter
may call a domain-neutral binding-receipt port beneath that mapping. The port
knows tenant scope, namespace, caller key, opaque bindings, and receipt identity.
It never knows what a Call, forecast, decision route, refusal, or learning record
means.

The exact `@konstantdotcloud/boombox` release pinned in `harness/package.json` exports the domain-neutral
`boombox.binding-receipt.v1` port, offline verifier, memory reference, and
`runBoomboxBindingReceiptConformance()` from
`@konstantdotcloud/boombox/receipts`. The Precise file adapter implements that
public port and passes its conformance suite. This proves contract compatibility
and local create-only custody; it does not prove a hosted Boombox receipt service,
connected Product-account tenant binding, or live custody. The receipt is run-less,
grants no effect authority, and does not mint an application or workload `run_id`.
Boombox workload control separately owns logical workload `run_id` values plus
admission and lifecycle Receipts.

```text
Precise Product core → Decision Learning → Precise publication adapter → BFF / UI / MCP
                                                   |
                                      opaque binding-receipt port
                                         /                    \
                       Precise conformant file         hosted Boombox custody
                         custody (local)                (not connected here)

Hosted durable work → Boombox workload control → host-minted run_id + lifecycle Receipts
```

## Standing Gateway application boundary

The first owner-operated Precise Gateway now has one concrete application
artifact boundary. From `harness/`, `npm run build:gateway-bundle` produces a
byte-deterministic unsigned
`application/vnd.boombox.app-bundle.v1+tar+gzip` archive and ConnectorBundle.
The bundle declares `connector_id`, `connector_version`, tenant, empty tool
surface, and `{artifact_sha256, entrypoint, port}`. Its digest must equal the
application descriptor's `artifact_digest`. Precise ships no signature or key.

Boombox owns the next steps: resolve a tenant signing key, sign the exact
ConnectorBundle, retain signed-manifest and attestation references, apply the
descriptor, run the fixed `/health` and `/harness` profile, and return
Deployment plus immutable revision-record identities. The Precise descriptor
builder consumes those references and declares an effect-free harness-only
application with no frontend, MCP path, external intent, secret, data handle, or
connector grant. A green extracted-process test is artifact proof, not proof
that any of those platform steps ran.

Per-operation continuity is adjacent to Product truth, not inside it. The Gateway
uses the package-pinned published platform kit to mint `boombox.app-operation.v1` and call the
tenant-authenticated host route; the host alone writes its store. The opaque
`product_session_ref` is a Precise episode ref. The operation `outcome` is only
`ok|refused|error` for the host operation, never a Precise judgment. The
host-emitted application revision record is the evaluation join, and neither it
nor the app-operation becomes a workload `run_ref`. The Gateway seals the joined
evaluation locally against that exact revision record and verifies it offline;
Precise does not deliver it to Boombox. Platform evaluation delivery is a later
host contract, not a developer credential or a Precise-side workaround.

The same application can mount the neutral Gateway math catalog and Precise's
continuing workflow surface. Precise owns the method catalog, mathematical
implementations, workflow definitions, input transforms, result interpretation,
and Product artifacts. Boombox may host the process, bind the caller and tenant,
persist opaque records, and deliver signed outcome-head events. Hosting does not
turn Product policy into a Gateway concern or transfer ownership of the math.

Workflow outcome delivery is pointer-based: the Product writes exact bytes to
tenant-bound create-only custody, and Boombox delivers the signed head event.
The Precise reader checks tenant, subject, sequence, digest, bytes, and workflow
identity before appending a cycle. Unrelated subject kinds pass to their own
handlers; sharing the event door does not make every event a workflow outcome.

The workflow record is execution history, not Product or host authority. It
retains complete step inputs and outputs plus raw run references and accepted
outcomes. Decision Learning still owns customer decisions, actual exposure,
mature observations, scores, and lessons. Boombox still owns host operation and
deployment records. None substitutes for another.

For the full Precise handoff and its first vertical slice, give
[`KONSTANT-BOOMBOX-ASKS-CONSOLIDATED.md`](KONSTANT-BOOMBOX-ASKS-CONSOLIDATED.md)
to a Boombox builder. It is the short reading index. The generic workload host
and first customer-owned GCP adapter now exist; several broader platform ports
and the exact Precise assignment-bound consumer path still do not.

For application plan, apply, preview, promotion, rollback, and retirement, use
[`BOOMBOX-DEPLOY-LIFECYCLE-REQUIREMENTS.md`](BOOMBOX-DEPLOY-LIFECYCLE-REQUIREMENTS.md).

For durable harness jobs, retries, recovery, and operator reattachment, give
[`BOOMBOX-WORKLOAD-CONTROL.md`](BOOMBOX-WORKLOAD-CONTROL.md) to both sides. As
of 2026-07-17, Boombox has an authenticated workload authority, durable control
state, a customer-owned Cloud Run Jobs/GCS provider, recovery, receipts, and a
bounded live Precise proof. Precise has the worker protocol, an assignment
consumer bridge, a package-pinned `@konstantdotcloud/boombox` plan binding, and
the authenticated public control client. The remaining seam is one exact
assignment-bound live Precise traversal through that client. Workload control is currently an
adjacent host service, not one of the 26 aggregate `Boombox` ports.

## The rule

A normal service should take the Boombox defaults. A service may replace a port when it needs specialized compute, a private data plane, a different cloud, stricter residency, or stronger durability.

The replacement still uses the same contract. It must register itself in the topology, bind Boombox identity and tenancy, emit Precise telemetry, and preserve the normal evidence and policy rules.

Boombox is the paved production path. It is not a limit on what a Precise service can run.

## Current typed surface: 26 ports

### Evidence and learning

| Port | Precise calls it to | Boombox must provide |
|-|-|-|
| `ledger` | Append and verify sealed events | Durable, atomic, ordered chains scoped to a tenant |
| `decisions` | Store a decision with the inputs needed to replay it | Durable lookup by tenant, decision, and time; byte-reproducible verification |
| `results` | Store ablations and matured outcomes | Append-only, queryable training and audit records |
| `evals` | Record eval runs and compare them over time | Durable history for regressions and promotion gates |
| `mappingMemory` | Recall a human-ratified source mapping | Tenant-isolated memory with no cross-customer recall |

### Network, tenancy, and company boundaries

| Port | Precise calls it to | Boombox must provide |
|-|-|-|
| `topology` | Read a scoped network view, append an expansion, or discover a service | Versioned graph storage, optimistic concurrency, append-only history, signed projections, and entitlement-scoped discovery |
| `tenants` | Provision a tenant's physical boundary | Datasets, row policies, perimeters, and grants that match the declared isolation spec |
| `auth` | Bind an authenticated request to a tenant path | A non-forgeable identity-to-tenant binding |
| `egress` | Send a sealed aggregate across a boundary | One deny-by-default exit that rejects raw or unsealed data |
| `pooling` | Compute a permitted aggregate across tenants | A controlled enclave with stable pseudonyms and no raw-data escape |
| `settlement` | Reconcile a decision accepted by two networks | Independent seals and verifiable cross-network settlement |

The topology has two kinds of relationships. Konstant supplies the business graph: companies, people, mandates, applications, capabilities, and accepted expansion. Boombox supplies the runtime graph: tenants, services, deployments, policies, data handles, health, and telemetry.

Those graphs can refer to each other, but they are not the same thing. Finding a service does not authorize a command. `topology.discover()` returns `invocationAuthorization: "not-evaluated"`; the normal auth and command gates still run.

### Data access and privacy

| Port | Precise calls it to | Boombox must provide |
|-|-|-|
| `warehouse` | Open tenant-local handles and run aggregate reducers | Pushdown compute where the data lives; no raw rows returned across the port |
| `sources` | Register and list source connections | Durable, idempotent source lifecycle and tenant isolation |
| `scanBudget` | Admit a warehouse read | Byte and time caps with tenant cost attribution |
| `kanon` | Apply minimum-group and pseudonym rules | Stable keyed identities and fail-closed group privacy |

Concrete connectors sit behind these ports. A Snowflake, BigQuery, DSP, ad server, or chain-data adapter does not contain Precise policy or scoring logic.

### Models, compute, and money

| Port | Precise calls it to | Boombox must provide |
|-|-|-|
| `llm` | Make a model call after Precise has redacted and admitted it | Tenant key isolation, provider routing, exact usage, and bounded failure |
| `budgets` | Check whether the next call or action is affordable | One authoritative tenant budget and a concurrency-safe admission decision |
| `costs` | Record and query attributed usage | Durable, idempotent cost records |
| `compute` | Run a pinned worker such as the canonical Shapley implementation | Deterministic inputs and outputs, a content-addressed run id, and fail-closed errors |
| `clock` | Supply time used in sealed or replayable work | Injected deterministic time in tests and an attested production clock |

`compute` is a good example of a service-owned override. A Trace contribution service may run its own Python worker fleet. Boombox still discovers it, deploys or attaches it, binds its identity, and operates it through the same port.

### Execution and operations

| Port | Precise calls it to | Boombox must provide |
|-|-|-|
| `dispatcher` | Execute a sealed and admitted move | Durable delivery with an atomic idempotency claim |
| `reconcile` | Fetch delivery and write the terminal result | Idempotent outcome reconciliation with signed provenance |
| `observability` | Emit a payload-free Precise telemetry event | Buffering, retry, export, retention, and visible delivery failures |
| `secrets` | Resolve a secret reference at runtime | Grant-based access, tenant isolation, and no secret values in logs or records |
| `deployer` | Build and publish a Precise cassette | Signed releases, deny-by-default command allowlists, provenance, and rollback data |
| `hitl` | Verify a ratifier or resolve consent | Non-repudiable identity tied to the exact approved artifact |

Telemetry is operational. Ledgers and receipts remain the evidence. A log line cannot replace a decision record, seal, eval run, or result.

## Host services that are not aggregate ports

Boombox also needs a few pieces around the `Boombox` object:

- Deploy a harness service and give it workload identity, network policy, scaling, health checks, and rate limits.
- Schedule `runContinuous` and registered jobs with idempotent run keys.
- Put concrete `SourceConnector` implementations behind `sources`.
- Put signed `ExecutionAdapter` implementations behind `dispatcher`.
- Forward Precise telemetry through an OpenTelemetry collector or another host transport into logs, traces, metrics, alerts, and the Boombox operator surface.
- Keep a service and release inventory so the estate view can join declared metadata to current observations.

`startHarnessService()` is the portable Precise HTTP runtime. Boombox hosts it; Boombox does not replace its command, floor, eval, or evidence semantics.

## Deployment shape

The intended production composition looks like this:

```ts
// Target composition. Public workload authoring exists in
// @konstantdotcloud/boombox/workloads; authenticated control is a host API.
const bb = createBoombox({
  project: "precise-pipeline-prod",
  region: "us-central1",
  serviceAccount: "my-service@precise-pipeline-prod.iam.gserviceaccount.com",
  tenant,
});

await runPreciseCapability(input, bb);
```

Shared Precise products and services deploy in the United States by default.
Polymarket-specific runtimes and data deploy in Europe. The project, region, and
residency class are explicit composition inputs, not facts inferred from code
location or the controller's region. The same contract must work with another
authorized GCP project and service account, or with a conforming adapter on
another cloud.

The normal product path has two operated targets. First, Precise may admit the
qualified release into `precise-pipeline-prod` or another explicit Precise-owned
project for a pilot, sandbox, or Precise-managed deployment. Bounded provider
administration uses the Doppler-held Precise operator identity; Cloud Run uses
a separate keyless runtime service account. Second, the same immutable release
may be planned and admitted into a customer-owned project. That customer target
has its own target digest, tenant authority, placement, trust policy, residency,
network, secrets, billing, revision, verification, and lifecycle receipts. The
release is reusable; the deployment and mutable state are not inherited across
the trust boundary. Any data or state migration is a separate authorized and
receipted operation.

The topology stores the service account name and other references. It never stores a credential, bearer token, customer payload, or raw row.

## Platform extension points

Boombox stays ahead of shared infrastructure needs by absorbing each recurring horizontal requirement into one typed contract. The 26 aggregate ports remain stable while the following extension points sharpen the application, workload, discovery, and reference paths Precise consumes:

| Contract extension | Stable question it answers |
|-|-|
| Invocation authorizer | May this authenticated principal invoke this command on this capability under this exact topology revision? The answer must be a signed admission or refusal receipt. Discovery remains explicitly non-authorizing. |
| Domain-neutral binding receipt | How does an authorized caller create once or resolve an immutable, tenant/namespace/sub-scope binding between one caller key and canonically ordered opaque `{name, ref, digest}` values? Exact retries reuse; changed content conflicts; Product meaning is prohibited. The contract and conformance runner are public in `@konstantdotcloud/boombox@0.13.2`; hosted custody remains a separate unconnected service boundary. |
| Standing app-bundle | How does one deterministic unsigned Product service become a tenant-signed, immutable, health-checked application revision without sending signer material into the Product repository? |
| App operation | How does a Product service record one descriptor-declared host operation against an exact Deployment/revision/artifact while keeping Product session identity opaque and distinct from workload runs? |
| Precise assignment-bound workload control | The generic host already plans, applies, activates, invokes, recovers, reattaches, and reconciles a workload, and the public package carries its authenticated client. The remaining join must accept one exact Precise `ResearchRoundAssignment` without rewriting its full verification context, basis, physical plan, workload, placement, release, tenant, residency, evidence, or task identity. Its admission receipt binds `assignment_hash`, `assignment_context_hash`, `assignment_basis_hash`, `physical_plan_hash`, `workload_hash`, `placement_hash`, logical run, experiment/spec, implementation, exact task/stage, principal, topology, budget, verifier release, run key, and requested desired placement. Later attempt receipts bind the actual provider resource and observed placement. See [`BOOMBOX-WORKLOAD-CONTROL.md`](BOOMBOX-WORKLOAD-CONTROL.md). |
| Lifecycle-aware discovery | Which discovered service is live, ready, supported in this region, within capacity, and not retired? A reference to a health endpoint is not enough. |
| Reference resolver | How does an authorized caller resolve and integrity-check a `contractRef`, `policyRef`, `evidenceRef`, or artifact pointer? |
| Deployment lifecycle | How does a caller plan, apply, inspect, promote, and roll back a deployment with a typed target and receipt? The focused contract is [`BOOMBOX-DEPLOY-LIFECYCLE-REQUIREMENTS.md`](BOOMBOX-DEPLOY-LIFECYCLE-REQUIREMENTS.md). |

Some of these may extend an existing port instead of adding another top-level field. The important part is to type the behavior once and keep it out of each service's private plumbing.

Application qualification establishes the pattern. The exact public
`@konstantdotcloud/boombox` release pinned by `harness/package.json` carries the
opaque Precise-owned `{qualification_ref, qualification_digest}` pair and refuses
unqualified production plans. At apply and every promotion or rollback, the
Boombox lifecycle requires a tenant-authorized semantic verifier and binds its
payload-free result to the exact tenant, complete target digest, provider,
project, region, residency class, trust-policy digest, verifier-release digest,
artifact, manifest, and attestation. Accepted qualification and verification
receipt pairs propagate through revision state, inspect, lifecycle receipts,
and fleet projection. The SDK exports
`runBoomboxApplicationQualificationVerifierConformance()` for the accepted,
expired, verifier-release-mismatched, and placement-mismatched cases. Precise
continues to own every eval, floor, expiry, evidence, and qualification semantic.

The canonical `harness/` consumer pins one exact release and exports the Precise
semantic verifier adapter. Its public conformance contract covers accepted,
refused, expired, verifier-release-mismatched, and placement-mismatched cases,
and `precise.release-handoff/v2` carries the exact qualification pair into the
application descriptor. The verifier accepts only after a composition-root
loader resolves the exact immutable Precise qualification and a create-only
publisher stores the exact target-bound verification receipt. Current execution
evidence and the historical `release-source-closure-unbound` refusal live in
[`CONNECTIONS.md`](CONNECTIONS.md); the master plan owns the Product sequence.

Precise Decision Learning records do not require a Boombox research-specific port.
Precise verifies the independently authoritative primaries and writes a create-only,
content-addressed closure over their exact references and digests. Boombox may
persist that opaque closure through a tenant-bound create-only object store and may
index its identity through a domain-neutral append-once ledger. The Decision
Learning episode is recomputed from the closure and those primaries; `results` and
`evals` are derived projections, not episode authority. Boombox exposes an adjacent
authenticated workload host rather than adding `workloads` to `BOOMBOX_PORTS`.
Precise episode, closure, and assignment semantics remain opaque Product records
layered above it.

### Evaluation interoperability

Konstant stewards the canonical evaluation language; Precise owns every Precise
case, grader, floor, evidence meaning, product judgment, disposition, and learning
decision. The installed `boombox.evaluation.v1` contract carries canonical identity,
time, lineage, context bindings, configuration, execution, plural observations,
judgment, outcome, decision, custody, restatement, and first-class
`product_learning_authority_ref`. Precise maps each complete customer learning
history through the `precise.decision-learning` extension by immutable reference
and digest. A Call is one referenced forward-bet record within that history.

Product learning and Konstant capture are independent. A Precise Learning Decision
can authorize an exact Product update without granting rich Atlas capture. A
`capture_policy` or Learning Grant reference cannot teach a Precise model or
qualify a release. Payload-free service facts prove neither. Rich evaluation
execution reuses Boombox Run for durable work and reattachment rather than creating
another lifecycle.

The exact installed package and compatible gateway remain runtime authority. The
repository's `evals` port and local Decision Learning closure journal are Precise
adapters; they do not imply a live Evaluation Atlas service. The exact
cross-repository mapping and release work are in
[`PRECISE-TO-KONSTANT-EVAL-HARNESS-HANDOFF.md`](./PRECISE-TO-KONSTANT-EVAL-HARNESS-HANDOFF.md).

Precise now exposes
`createAdmittedResearchExperimentWorkloadBridge()` as the tested consumer side
of this boundary. It derives the exact admission expectation from one verified
assignment and returns no handler until an injected verifier accepts an
already-issued opaque receipt. That proves the typed join; it does not implement
Boombox admission. `createBoomboxResearchWorkloadBinding()` separately binds the
same Precise program to the exact public Boombox descriptor, target, and
non-authoritative plan. The first slice supports one experiment task and refuses
multi-stage semantics rather than guessing them.

## Current implementation boundary

Built and tested in this repository:

- the Precise-owned media Next-Dollar publication adapter, which preserves the
  exact Product result and maps its records into opaque bindings;
- the Precise create-only file adapter behind the public
  `boombox.binding-receipt.v1` port, with package conformance, deterministic
  tenant/sub-scope mapping, exact retry, changed-content conflict, scope-bound
  absence, tamper refusal, same-process race, and fresh-process reattachment
  coverage; it is local custody, not a hosted Boombox service;
- the 26-port `Boombox` TypeScript contract;
- local implementations for `ledger`, `decisions`, `results`, `evals`, `mappingMemory`, `warehouse`, and `costs`;
- a fixed local `clock` and visible, best-effort stderr `observability`;
- explicit `NOT_LOCAL` failures for infrastructure that cannot be faked locally;
- lazy harness attachments and the generated HTTP service surface;
- the Precise telemetry event and sink contract;
- the estate catalog, dated GCP observations, and agent-readable source index;
- the versioned network topology, expansion validator, and scoped service discovery contract.
- the Precise-side, single-task admission expectation and verifier port joining
  one exact assignment to the real research harness and generic workload handler.
- a package-pinned public Boombox workload descriptor/target/plan binding that
  rejects tenant, program, runner, implementation, and placement drift before
  admission.
- a package-pinned public `@konstantdotcloud/boombox` application
  descriptor/target/plan binding in the canonical harness and founder/CTO demo;
  the harness carries the opaque Precise qualification pair, refuses unqualified
  production plans, exports the Precise semantic verifier adapter, and passes
  the public five-case conformance proof;

Built and live-proven in Boombox Plan057, outside this repository:

- host-minted logical workload `run_id` values, caller-supplied idempotent
  `run_key` bindings, admission Receipts, and terminal lifecycle Receipts;
- authenticated apply, activate, invoke, and read-only run attachment routes;
- durable workload state with fencing, CAS, replacement-controller recovery,
  terminal receipts, and exact provider observation;
- customer-owned Cloud Run Jobs execution and GCS runtime/result/receipt custody;
- one bounded Precise research-eval run proving duplicate-trigger identity,
  controller replacement, reattachment, and terminal result custody;
- one signed payload-free monotonic fleet projection. It is one managed stream,
  not yet tenant-wide aggregation or a billing ledger.

Built and live-proven in Boombox Plan059, outside this repository, as the first
real customer-cloud application proof:

- the application lifecycle ran end to end against one disposable private
  Precise canary: plan, pre-provider regional refusal, apply, duplicate apply
  adopting one logical deployment, replacement-controller adoption, private
  authenticated invocation, fresh-session inspect, healthy and then retired
  payload-free fleet projection with `charge_authority:false`, verified apply
  and retirement receipts, and independent provider-absence proof after
  retirement;
- unauthenticated, wrong-principal, wrong-tenant, and cross-tenant inspection
  refused;
- the image ran the same-origin Precise frontend plus authenticated harness in
  customer-owned `precise-pipeline-prod`, US placement, customer-billed; the
  image and immutable release objects stayed in Precise custody; Konstant held
  only an isolated tenant control DB and the signed payload-free fleet record;
- no customer payload, secret, mutation authority, or customer-data movement
  entered the proof. It does not prove restricted networking, arbitrary app
  import, public-read hosting, qualification-gated promotion/rollback, or a
  production customer-data product.

Source identity discipline for that proof: the live canary artifact was built
from Precise commit `312479c4` (image digest
`sha256:5c978fc13b96b81f93082fcb71ac05f189009b4a9855da84a55704691960af9c`) and
stays labeled as that historical identity. The qualification and demo-path
tooling landed after the proof (`720a3f7c` and successors) and does not
retroactively describe those bytes: `npm run demo:preview` therefore refuses a
new promotable handoff for the historical artifact
(`release-source-closure-unbound`) and emits a historical verification report
until a rebuilt artifact records its build closure at build time.

The current Precise product roadmap pulls the following platform work through the same Boombox boundary:

- the production implementation of the full 26-port `Boombox` object (the
  published `@konstantdotcloud/boombox` package is intentionally an authoring
  surface rather than that complete runtime authority);
- the complete authenticated live topology registry and tenant-wide signed
  projections beyond the one proved workload stream;
- production tenant binding, provisioning, and egress enforcement;
- durable adapters for every store that needs them;
- the telemetry collector and operator projection;
- signed cassette deployment and the continuous scheduler.
- exact assignment-envelope verification and an assignment-bound Precise worker
  image/run through the existing public authenticated workload-control client
  and generic host;
- tenant-wide projection aggregation, a customer-local relay, production secret
  resolution, automated provider TTL cleanup, and billing/rating settlement.
- hosted binding-receipt custody with authenticated Product-account tenant
  binding; the public package-pinned contract and Precise file conformance do not supply it.

The local `DecisionStore.verify()` only checks that a seal reference exists. The production adapter must replay the stored inputs and verify the derived seal. That gap is explicit; the local result is not a production proof.

The exhaustive guarantees, acceptance tests, and open questions remain in `docs/atlas/BOOMBOX-INTEGRATION.md`. This document is the first read; that document is the implementation appendix.