MIZ OKI Signal — Launch Kit v1

Date: 2026-08-25
Product: MIZ OKI Signal
Launch posture: prepared for governed review; not a public-launch authorization
Capability table of contents: FEATURE_COVERAGE_MATRIX_v1.md

1. The offer

MIZ OKI Signal is the governed Growth Control product defined by:

• SIGNAL_OVERVIEW_v5.md — product overview, content version 5.3;
• SIGNAL_SHOPIFY_MASTER_v4.md — Shopify build and operating specification;
• MIZOKI_SHOPIFY_OFFERING_AUG2026.md — merchant-facing offering;
• MIZOKI_MARKETING_AUTOMATION_WHITEPAPER_r2.0_SEP2026.md — marketing-system context (r2.0 supersedes r1.2 + amendments r1.3/r1.4; archived under docs/marketing/history/).

The offer is evidence-first and observe-first:

1. connect the merchant's approved commerce, marketing and analytics stack;
2. reconcile outcomes against validated cost and margin inputs;
3. define the High-Value Decision Jobs to evaluate;
4. produce governed evidence, refusals and recommendations;
5. route material decisions to named humans;
6. expand authority only after capability-specific real-data evidence and approval.

No document in this kit guarantees an outcome. Status labels and public figures remain governed by the claims ledger.

2. Feature and status index

The complete inventory is FEATURE_COVERAGE_MATRIX_v1.md. It records:

• the implementing artifact for every feature;
• the strongest honest status: LIVE, PARTIAL, IN BUILD, or PROPOSED;
• the customer or operator demo moment;
• the launch surface;
• every named gap or evidence condition.

Important launch interpretations:

• F4 is IN BUILD — live-armed, L2 approval-gated. The live schedule and holdout evidence do not silently promote the canon label.
• Anticipatory intent is evidence from privacy-bounded, content-free behavior. It is not mind reading and remains Preview/in-development where required.
• The pilot report is a skeleton until real evidence exists. Empty verified numbers are the correct launch state.
• Writebacks remain off. Recommendation evidence is not execution authority.

Launch surface → console. The matrix's "Launch surface" cells for the latent report views (rows 2.6, 3.2, 6.5) name console routes under /latent in miz-oki-command-center-ui/ (lib/console/destinations.ts); the console is the launch surface, and this kit and the matrix remain the audit surface (Wave 2 WS-6, 2026-09-02; status IN BUILD until a measured deploy).

3. Entry product — the 90-Day Growth Control Pilot

The standard commercial entry is PLAYBOOK.md.

Days 1–30 — Observe

• connect the agreed stack;
• establish baseline data quality;
• complete costs and governed tenant intake;
• define J-01 through J-06 Decision Jobs in scope;
• retain L0 authority and zero live execution changes.

Days 31–60 — Validate

• register qualified holdout/experiment designs before exposure;
• calibrate CATE and propensity evidence;
• reconcile margin against the customer's own books;
• record prediction quality and refusal behavior.

Days 61–90 — Recommend

• deliver contextualized proposals with evidence and complete audit trails;
• route every material proposal through named human approval;
• grade predictions against outcomes;
• assemble the pilot report and claim-ledger evidence.

The sequence is a product contract, not a slogan. A phase advances only when both the day window and its evidence checklist are satisfied.

4. Onboarding

The authenticated onboarding UI is the source of truth under .claude/rules/tenant-onboarding.md.

A tenant supplies:

• authenticated organization and pilot scope;
• selected Decision Jobs and explicit F1–F5 scope;
• required connector/account/property identifiers and authorizations;
• COGS_WORKSHEET.md values and validated cost inputs;
• treasury floors, covenants, proposal caps and dated cash where F5 is selected;
• F2 discount factor and supported LTV inputs;
• F3 SKU thresholds, holding costs and freshness bounds;
• F4 geographies, panels, exclusions, perturbation bounds, reservation limits and spend caps;
• F1 creative access, licensing and approval ownership;
• consent, retention, erasure and named human approvers.

The platform returns named gaps. Missing values remain not_configured; they are never invented in chat, code or an operator worksheet.

Collected is not armed. Saving onboarding data does not start a pilot, register a holdout, reserve a geo, flip a flag, widen autonomy, approve a decision or dispatch an action.

5. Shopify merchant path

Merchant-facing copy is maintained in shopify-app-listing-copy.md.

The intended path is:

1. merchant enters the governed install flow;
2. OAuth state and callback signature validate;
3. token custody and shop-to-tenant registry activate in the correct order;
4. approved webhook/compliance subscriptions and Web Pixel setup complete;
5. commerce truth and approved marketing connectors become healthy;
6. COGS/economics and pilot intake complete;
7. human review places the tenant into Day-1 Observe.

The machinery is implemented across the Shopify gateway and onboarding stack, but a real merchant end-to-end proof is still required. Until then, public copy retains Preview/direct-pilot posture rather than claiming universal App Store availability.

6. Proof surface and demo

The governed demo sequence is DEMO_STORYLINE.md.

Demo surfaces → console. The demo views are served by console read APIs, never by a parallel backend: D-1 (SIG-042 passport spine) at /command-center/passports/[decisionId] over /api/bff/passports/[decisionId]/package; D-4 (L1 Profit-Leak, L5 Restraint Ledger) at /latent/profit-leak and /latent/restraint-ledger; D-3 (dosage + DEL curves) has no governed read and is not surfaced — /latent states that as [not-wired]. Docs remain the audit surface.

SIG-042 spine

The Signal Factory demonstrates a composite, illustrative scenario:

• a performance symptom appears;
• the platform investigates cross-stack causes rather than blaming media reflexively;
• unsafe alternatives are refused;
• a governed recommendation is assembled with evidence, constraints and audit context.

SIG-042 remains illustrative until a verified customer case study satisfies the claims ledger.

O-1 rejection moment

The demo must include a prohibited-signal submission—audio, keystroke dynamics, gaze or fine-grained location—and show rejection before storage or hypothesis creation. Governance is a customer-visible behavior, not a footnote.

ValidationPassport moment

A decision package should be assembled, signed with the governed KMS path, verified, and then tampered so verification fails. The package is a read model over the existing decision objects, never a ninth object.

F4 moment

Use the recorded live F4 posture honestly:

• approved tenant configuration exists for mycocoons;
• a Cell 36 holdout was registered before reservation submission;
• the proposal entered the L2 approval queue;
• the actuator is deliberately absent from action-runner, so the proposal cannot spend.

Do not demonstrate a live mutation merely to make the demo look more autonomous.

7. Customer reporting

The pilot report shape is generated by contracts/mizoki_contracts/pilot.py and governed by the 90-day state machine.

Reporting surface → console. The L1 / L5 / L2 report views live in the console under /latent (index /latent maps each to its coverage-matrix row); every view carries the ILLUSTRATIVE watermark until the claim ledger verifies pilot numbers, and "no data" renders as no data. The pilot report itself remains the document deliverable; docs remain the audit surface.

It assembles:

• pilot phase/history and selected jobs;
• ValidationPassport package identifiers;
• calibration and propensity references;
• margin-reconciliation evidence;
• evidence-maturity gate artifacts;
• verified numbers when—and only when—real pilot results have been recorded.

At launch, verified_numbers may correctly be empty. Synthetic fixtures and illustrative demos do not upgrade claims.

Weekly cadence

The named business, technical, finance/privacy and approval owners are collected during onboarding for each tenant.

8. Claims governance

The claims source is claims-ledger.yaml, enforced with TRUTH.md and the marketing content gate.

Rules:

• every public number is ILLUSTRATIVE, SIMULATED, PREVIEW, or TARGET until ledger-verified;
• Preview labels change only after real evidence is entered through the governed claim process;
• implementation, deployment and live verification are distinct states;
• a real mechanism does not imply a measured customer result;
• anticipatory intent is never marketed as telepathy or access to private thoughts;
• Shopify availability is not claimed beyond the verified distribution/install posture;
• status changes require the canon/status sources to move together.

9. Inquiry path

The canonical tracked CTA is /go/pilot on the existing landing surfaces. It uses a closed destination registry and adds a [ref ...] token for attribution.

Launch verification requires:

1. live redirect and destination verification;
2. a separate email tagged SYNTHETIC-VERIFICATION in the subject and payload;
3. proof that a human recipient receives it;
4. exclusion from A/B/C experiment counts through the bot/synthetic policy.

Randomized A/B/C assignment remains dark unless separately armed. The canonical page remains /signal, and the pre-registration/SRM tools remain the analysis contract.

10. Governance and execution boundary

MIZ OKI Signal executes through one path only:

Evidence → Validation → Policy/DEL → DCP authorization → Action Runner → adapter

An optimizer, scorer, scheduler, report generator or user-interface component never calls an advertising platform directly.

The execution boundary includes:

• registered holdout before causal activation;
• consent and sensitive-category checks;
• treasury and hard-constraint vetoes;
• named human approval where required;
• single-use authorization;
• tenant allowlist and capability kill switch;
• action-runner adapter registration;
• Act-time revalidation;
• rollback and audit evidence.

11. Dark surfaces and later evidence gates

12. Launch gates

This document is not an approval token.

• APPROVED: MERGE allows the non-site launch package to land after rebase and full gates.
• APPROVED: DEPLOY allows the governed shadow/deploy verification sequence.
• APPROVED: LAUNCH alone allows the held, one-commit public surfacing change.
• APPROVED: PILOT starts one tenant only after validated intake and readiness re-verification.

Public surfacing must be one revertable commit with its rollback command written before push.

13. Standing product sequence

30 days Observe
→ 60 days Validate
→ 90 days Recommend
→ governed claim ledger
→ verified Preview-label changes
→ each writeback only after its own pilot
→ remaining F-autonomy after clean cycles and human gates
→ Stage-4 authority per capability, two-key execution intact

The first customer's evidence—not another unsupported claim—is what upgrades the product labels.