SUPERSEDED by docs/marketing/MIZOKI_MARKETING_AUTOMATION_WHITEPAPER_r2.0_SEP2026.md

WHITEPAPER AMENDMENT r1.4 — CROSS-DOMAIN INTEGRATION

Verification note (2026-08-26): every §14 claim below was checked against live code the same day this amendment was drafted (five independent read-only sweeps; citations are file:line, not doc-to-doc). Several claims in the original draft did not match shipped reality and are corrected here rather than published as written. Full evidence: docs/product/FEATURE_COVERAGE_MATRIX_v1.md §10 and docs/product/CONNECTOR_GAPS.md.

§14 — THE PLATFORM UNDER THE MARKETING PRODUCT

MIZ OKI Signal is one desk of a cross-domain decision system (whitepaper r3.5.1). These platform-level capabilities carry the marketing product and are documented here with honest labels; none is claimed beyond its verified state.

§14.1 Connector Ingestion Paths [PARTIAL]. There is no single named "Unified Connector Gateway" in code — three separate mechanisms exist: the deployed service-canonical-ingestion HTTP service (wraps requests in the live CanonicalEventEnvelope schema v3.5.1, contracts/mizoki_contracts/envelope.py), the in-process MAPPERS[source] → ingest_gate dispatch (src/shared/virtuoso_models/transforms/mappers.py:434-440, a different envelope shape per journey-event.json), and an unrelated Boss-agent outbound tool registry (miz-oki-adk-agents/boss/connector_gateway/tools.py) that is not an ingestion path at all. Of the 15 sources named in the original draft: 3 LIVE (Google Ads, Meta Ads, SendGrid), 4 PARTIAL/fail-closed (Shopify, GA4, Klaviyo, The Trade Desk), 1 IN BUILD/narrow (OpenRTB — mapped in the journey lane but has no HTTP adapter and is unreachable via service-canonical-ingestion), and 7 are not ingestion sources at all: Gmail, Drive, GitHub, and Calendar are Boss-agent outbound tools never wired to any ingestion path; BigQuery, Vertex AI, and graph storage are ingestion destinations (landing table, inference backend, KG projection target respectively), never sources. Customer benefit, honestly stated: every wired connector normalizes through one of two governed envelope paths, never a side door; every absent or misclassified connector is named here rather than implied. Full connector-by-connector table: docs/product/CONNECTOR_GAPS.md.

§14.2 Canonical Event Envelope [IN BUILD — schema convergence pending]. Three envelope schemas currently coexist in the repo. The ten-question framing in the original draft describes the v1.0.0 schema tree (contracts/canonical-event-envelope/), which its own README marks superseded and subordinate as of 2026-07-27 (MIZ-REC-2026-003), with convergence tracked at docs/INTEGRATION_PLAN.md DATA-001. The authoritative, live envelope is schema v3.5.1 (contracts/mizoki_contracts/envelope.py), which does not carry the ten-question structure — its fields include no named policy, objective, or causal-context sections. Even within the superseded v1.0.0 tree, 3 of the 10 questions (why · which objective · which policy governs) map only to untyped, schema-unenforced empty objects (causal_context{}, business_context{}, governance{}), not modeled fields. Corrected claim: every live envelope path answers what-happened / who-was-involved / what-action-could-be-taken / what-risk-exists / what-was-predicted / what-actually-happened / what-should-be-learned; why / objective / policy remain design intent in the superseded schema, not shipped structure in the live one.

§14.3 Decision Authorization Path [PARTIAL]. The "Four Deterministic Decision Gates" framing in the original draft does not match code. The live mechanism is a single DEL score — a linear weighted average, 100*(0.5*passport_pass_rate + 0.3*evidence_completeness + 0.2*verification_weight) (services/service-policy-engine/main.py:116-120) — HMAC-signed at the DCP (services/service-decision-control-plane/main.py:94-96), preceded by roughly nine sequential veto/threshold checks inside evaluate() (treasury veto, supply-chain veto, critical-materiality block, passport-pass-rate floor, domain advisory/approval gates, media-experiment-evidence check, DEL threshold, value-ceiling, reversibility — services/service-policy-engine/main.py:110-222). Caller identity/signature verification is a separate, uniform FastAPI dependency (Depends(verify_caller), contracts/mizoki_contracts/auth.py:85) applied to every endpoint, not a gate inside this pipeline. This is Feature Coverage Matrix Gap G-18 (canon describes clipped-ReLU; code implements a linear weighted average — concept correct, activation-function shape differs). Customer benefit, unchanged: a proposal below threshold is blocked with the constraint named in the passport; above threshold, it is authorized with a signed proof. The mechanism doing that work is real; it is not organized as four named gates.

§14.4 Autonomy enforcement [PARTIAL, shipped] · six-tier L0–L5 ladder [ROADMAP]. No L0–L5 enum exists anywhere in code, not even unwired (contracts/mizoki_contracts/decision_objects.py:55-57 defines exactly STAGE_3_RECOMMEND_ONLY and STAGE_4_BOUNDED_AUTONOMY). The 90-day pilot's Observe/Recommend/Approval language is narrative and consistent with this two-stage reality: pilots run recommend-only until a human POST /api/v1/actuators/stage promotes to bounded autonomy (services/service-action-runner/main.py:226-241) — there is no automated promotion evaluator (Feature Coverage Matrix Gaps G-19, G-20). The "two-key rule" is real but is actually three enforcement points, not two: the DCP's actuator-registry ceiling (services/service-decision-control-plane/main.py:99-111), the action-runner's independent re-check (services/service-action-runner/main.py:117,319,459), and the presence of a real execution adapter (services/service-action-runner/execution_adapters/base.py) — applied per-message in Cell 39 as well (src/cells/cell39/outreach_cell/dcp_gate.py). Corrected claim: the six-tier L0–L5 ladder is roadmap vocabulary used narratively across docs, not an implemented enum; the enforced reality today is two stages, manual promotion, and a three-part actuation check.

§14.5 Domain Desks [ROADMAP — demo/marketing-site engines, not production cells]. Counsel Room, Capital Desk, Estate, Risk, and Nexus Boardroom all exist as deterministic, fixture-only engines on the marketing site (demo_counsel.py, demo_capital.py, demo_estate.py, demo_risk.py, demo_nexus.py — each stdlib-only, no LLM calls, no production or tenant data access) surfaced at /demo/* (e.g. index.html:837 links "Nexus Boardroom" to /demo/nexus; the code itself calls the chained scenario "the Nexus Run"). docs/OFFERING_MAP.md (row 5) is explicit and current: Capital, Risk, and Estate cells do not exist in the fleet — labeled PROPOSED; only Counsel has even demo-grade presence, labeled PARTIAL. The ACT-991 scenario is real and already correctly labeled an illustrative scenario in TRUTH.md/GOVERNANCE.md/AGENTS.md — never a customer result. Correction: the original draft's "spec-per-r3.5.1" attribution is false; docs/MIZOKI_3.5_WHITEPAPER_r3.5.1_AUG2026.md contains zero mentions of Counsel, Capital, Estate, Boardroom, or ACT-991 — it does not spec any Domain Desk. F5 treasury machinery is confirmed tenant-scoped to the marketing product only; a Capital-division feed does not exist (contracts/mizoki_contracts/treasury_feed.py:44-56 raises NotImplementedError). Customer benefit, honestly stated: the demo engines illustrate that the SRPVDAL/gate architecture generalizes narratively; no non-marketing desk is built, wired, or claimed as a product today.

§14.6 Growth Decision Graph scope [PARTIAL — marketing-scoped, not cross-domain]. The Growth Decision Graph has exactly one writer today: F3 supply-chain/inventory sync (src/cells/cell37/market_cell/f3_inventory.py:504, project_to_growth_decision_graph), observe-only per owner ruling. No treasury, legal, or estate module reads or writes the graph. F5 treasury constraints reach the marketing decision path as a direct, in-process config check inside the policy engine (contracts/mizoki_contracts/treasury.py:223 → services/service-policy-engine/main.py:126), never via a graph edge. Counsel Room exists only inside the demo runtime, not as a production legal service. README.md:68 states this directly: "Growth Decision Graph intent edges | PARTIAL — observe-only / shadow." Corrected claim: F5 and F3 constraints do reach marketing decisions as hard vetoes — that mechanism is real and already documented in §9/§13 — but they do so as intra-product policy-engine checks, not as reads/writes against a graph shared across desks. No desk outside marketing shares this graph today.

Discipline: content_qa covers only the nested # MIZ OKI 3.5/ marketing-site subtree, not repo-root docs/marketing/ or docs/product/ — that gap (Feature Coverage Matrix Gap G-25) was found while drafting this amendment and is now closed: scripts/check_canon_docs.py gates both paths in CI (content-truth-gate job, ratchet baseline scripts/canon_docs_baseline.json), and this document scans clean. Anticipatory-intent framing governs. Targets are not results until the claim ledger says so.