Engineering: a working system
The system contract, data flow, API boundaries and evidence required to trust a complete Brand Studio run.
Goal and current truth
Goal: make the supported Brand Studio workflow fully working and understandable, from one confirmed URL through a quoted plan, authorized execution, durable evidence, analysis and a report whose claims, quantities and charges reconcile.
An operator should be able to understand what was collected, what is missing, why each conclusion follows, and what it cost without reading implementation code. Alaris is the initial acceptance case; it is not the only shape the system must handle.
This manual is a source-grounded engineering specification and inventory. It is not a claim that every contract below already passes. A module can exist in source while its full runtime path remains unverified. Current-source observations, historical results and required future evidence are labeled separately.
Current inspection on 2026-09-13: the quote/compiler/docs/ledger/queue suites pass locally, a disposable PostgreSQL proof measured the settled-ledger reduction, and authenticated no-spend Snapshot/Market/Deep quotes matched execution source manifest 9d41aa65. The later local account-observation and receipt work changed the manifest to 312ccd6a, so those quotes are retained historical evidence and cannot authorize current execution. The one authorized Deep acceptance attempt spent an isolated $0.447132 and failed at the Supabase transport seam before a report or execution receipt existed. Paid acceptance has not passed.
Three connected product layers
| Layer | Input and output | User-visible proof |
|---|---|---|
| Evidence collection | Confirmed identity, market and selected modules → source records and request receipts. | Source, date, target, requested/returned counts, truncation and failures are inspectable. |
| Analysis and interpretation | Validated evidence → normalized fields, claims and derived conclusions. | Each factual claim points to evidence; inference and uncertainty are explicit. |
| Report and decisions | Normalized results and receipts → saved report, exports and actionable next steps. | Reloaded report and export agree with the selected plan, evidence and charges. |
One acceptance journey
Engineering ownership
| Role | Responsibility | Acceptance boundary |
|---|---|---|
| Opus 5 lead engineer | Own system architecture, contract decisions, root-cause adjudication, sequencing and integration review. | Decisions explain observed evidence and unresolved assumptions; review alone is not runtime proof. |
| Sonnet: data and APIs | Inventory field schemas, database/storage, public and provider contracts, normalization, queue persistence and migration risks. | Every supported transition has a producer, consumer, schema, failure mode and regression evidence. |
| Sonnet: verification and evals | Own end-to-end reproduction, independent oracles, representative cases, fault injection and evaluation coverage. | A failure in identity, spend, privacy or completeness cannot be averaged away. |
| Coordinator | Maintain the shared goal, source documentation, evidence, approvals and tracker projection. | Record actual models and run receipts; do not silently substitute agents. |
Scope and non-goals
Fully working means the explicitly supported scope is complete and truthful. Inventory all catalog modules, including free and parked items; activate only modules with implemented adapters, resolved targets and verified pricing. AI visibility and unpriced provider lanes stay parked.
The earlier single funded attempt does not authorize a second pull. A future funded acceptance requires a fresh exact quote and approved cap. Live database changes and deployment retain their own approval gates.
Retain existing visual direction, source evidence and unrelated worktree edits. Prefer repairing the supplied implementation to adding a parallel pipeline or documentation system.