MIZ OKI 3.5 — Marketing Automation Architecture

Techniques, Processes, and the Governance That Bounds Them

Version: r2.0 · September 2026 Changelog r2.0: consolidation — this single document folds base r1.2, amendment r1.3 (§13, extended capabilities U1–U9) and amendment r1.4 (§14, the platform under the marketing product); §1–§12 are not renumbered and no capability status label changes. §8.1 is reconciled to the governing docs/architecture/DEL_AUTHORIZATION_FUNCTION.md: its §1 definition is quoted verbatim, its own status is stated in its own words (PROPOSED CANON v1.0; per-action-class parameterization [Roadmap], §7 [IN BUILD — not started]), and the shipped DEL score is named for what the code computes — a linear weighted average (services/service-policy-engine/main.py:176-178, Feature Coverage Matrix gap G-18) — so §8.1 and §14.3 give one answer; §4.1's disambiguation paragraph and the §12 summary row are aligned to the same statement. The governing-document citation is corrected from the non-resolving architecture/… form to its real repository path (including in the r1.2 changelog line below). §14.3's file:line citations were re-verified against the tree on 2026-09-02 and refreshed; no [VERIFY-CITE] markers were present in r1.2–r1.4, so the plan's "resolve or downgrade" criterion is satisfied vacuously; r1.2, r1.3 and r1.4 are superseded byte-for-byte to docs/marketing/history/ with cross-link stubs at their former paths. Changelog r1.2: added the Clipped-ReLU DEL Authorization Function (§8.1) — the evidence-to-authorization mapping is a named platform process, canonical in docs/architecture/DEL_AUTHORIZATION_FUNCTION.md (path corrected in r2.0); corrected §4.1, which had mislabeled ReLU as generic-only; Frontiers F1–F5 updated to PARTIAL (built flag-off in the 2026-08-19 completion run, activation gated on pilot configuration); summary table refreshed accordingly. Changelog r1.1: ghost bids corrected from "technique in use" to PROPOSED (implementation plan only, not claimed on any customer-facing surface); per-module retention bounds added to §3.1; MEASUREMENT_WRITEBACK and NET_YIELD_WRITEBACK flag status added to §7. Reconciled against the gated live surface at mizoki3.com/marketing. Companion documents: MIZOKI_3.5_WHITEPAPER_r3.6_SEP2026.md (folds r3.5.1 + amendment r3.5.2, 2026-09-02) · MIZOKI_SIGNAL_GROWTH_CONTROL_UNIFIED_SYSTEM_r2.0.md Supersedes: docs/marketing/history/MIZOKI_MARKETING_AUTOMATION_WHITEPAPER_r1.2_AUG2026.md (base) · docs/marketing/history/MIZOKI_MARKETING_AUTOMATION_WHITEPAPER_r1.3_AMENDMENT_AUG2026.md (§13) · docs/marketing/history/MIZOKI_MARKETING_AUTOMATION_WHITEPAPER_r1.4_AMENDMENT_AUG2026.md (§14) — archived verbatim behind a SUPERSEDED by header; the former docs/marketing/ paths carry cross-link stubs. The folded sections keep every label the amendments carried. Status vocabulary used throughout: LIVE (deployed and measured) · PARTIAL (shipped, incomplete surface) · IN BUILD (active development, not serving) · PROPOSED (designed, unapproved)

1. The Problem This Architecture Solves

Marketing automation has a measurement problem that no amount of automation fixes: the systems that spend the money also grade the results. Every ad platform reports conversions it believes it caused. Those reports overlap, double-count, and systematically flatter the reporting platform. Automating decisions on top of self-graded numbers automates the error.

MIZ OKI's position is narrow and specific:

Other tools optimize the number your ad platform reports. MIZ OKI optimizes the number your bank account reports.

Everything below serves that sentence. The automation techniques are conventional in places — the discipline around what those techniques are permitted to conclude is not.

2. SRPVDAL — The Seven-Phase Loop [LIVE]

Every decision the platform makes traverses seven phases. The phase is recorded in JourneyEvent provenance, so any output can be traced back through the reasoning that produced it.

The critical structural choice is PLAN and VALIDATE sitting between REASON and DECIDE. A system that reasons then decides will act on any confident inference. A system that must plan candidates and pass them through gates can produce a confident inference and still decline to act on it. Most of this document is about that gap.

Note on legacy naming: older documents reference a five-phase "SRDAL" loop. SRPVDAL is authoritative — it is encoded in the JourneyEvent provenance Phase enum. Legacy references map forward by inserting PLAN and VALIDATE.

3. Signal Acquisition [LIVE — cells 33–36]

Four dedicated cells carry the intent pipeline, deployed and IAM-locked:

Cell 37 (Data Injector) is existing brownfield infrastructure carrying external market signal as corroboration only.

Cell 28 is a legacy cell and was not repurposed. Intent scoring lives in Cell 34. Any document binding intent capability to Cell 28 is stale.

3.1 What is captured [PARTIAL]

Content-free behavioral signal: viewport deceleration, dwell duration, scroll velocity relative to user baseline, swipe vectors, partial watch depth, inline expansion pauses, tab blur/return, and form lifecycle events (form_started, field_focused, form_completed, form_abandoned) with coarse allowlisted field classes.

Signals are ordered into sequences with ULID sequence identifiers, batched client-side (25 events / 5s / pagehide, sendBeacon fallback) through the existing Shopify Web Pixel — extended, never duplicated by a second collector.

Retention is bounded per module, not by a global policy:

• I-01 — raw sequence buffers purge at session termination (ephemeral)
• I-02 — session forecast state exists only for the active session
• I-03 — asset representations expire on creative retirement
• I-04 — hypotheses expire by strict TTL and are revocable
• Erasure cascades through every relevant store

No persistent psychological dossier is created. The system recognizes a sequence within a session; it does not accumulate a profile across sessions.

3.2 What is permanently refused [LIVE — owner ruling O-1]

Rejected at the collector and again at ingestion, tagged DISALLOWED_KEYSTROKE_DYNAMICS:

• Raw keyboard, input, or composition events
• Entered text, key identity, or edit history
• Dwell/flight time, cadence, repeat rate, pressure
• Typing profiles, embeddings, fingerprints, baselines
• Audio capture of any kind; gaze tracking; fine-grained geolocation beyond consent-scoped coarse region

These are discarded at ingest, not stored-and-unsurfaced. Tests prove both directions: permitted lifecycle events validate, every rejected class fails with an explicit tag. This is a permanent owner ruling, not a configuration default — it cannot be flipped by a flag.

The reason is strategic as much as ethical. A capability you can be pressured into enabling is a liability on every enterprise security review. A capability the schema refuses is an asset.

4. Inference: Intent Engine v2 [IN BUILD]

Five modules convert signal into bounded inference.

4.1 The session sequence model [IN BUILD]

Cell 34 runs a compact causal transformer encoder — four layers, 128 dimensions, four attention heads — over tokenized behavior. Tokens are (signal_type, element_class, VDI bucket, dwell bucket, Δt bucket). No raw text or URLs enter the token stream.

Three heads: stage-transition-within-horizon, calibrated next-interest, and hesitation.

On architecture internals: the encoder's feedforward blocks use standard ReLU-family activations — ordinary neural network machinery. Separately, and not to be confused with it, ReLU also names the specified shape of the platform's authorization function: the Decision Eligibility Layer's authorization function is specified in clipped-ReLU form by docs/architecture/DEL_AUTHORIZATION_FUNCTION.md (PROPOSED CANON; the per-action-class parameterization is not yet built — the shipped DEL score is a linear weighted average, see §8.1 and §14.3). The model is CPU-sized to hold a p95 latency budget under 200ms, with a benchmark test enforcing it.

Labels come from the existing realized-outcome loop. Attention summaries join the explanation payload — an intent score is never served as a bare number. If the system cannot explain the inference, it does not surface the inference.

4.2 Creative-aesthetic alignment [IN BUILD]

Multimodal encoders vectorize creative variants into unified.creative_vectors, with per-customer decayed aesthetic-affinity vectors and RESONATED_WITH edges in the intent graph. Ranking sits behind its own flag, with automatic revert to default rotation implemented — not deferred as a TODO.

4.3 Latent bridges [IN BUILD — hypothesis-only]

The graph builds temporary bridge nodes linking disconnected behaviors into inferred states — B2B hiring research plus CRM pricing visits suggests an organizational scaling phase rather than two unrelated keyword triggers.

Bridges carry support, confidence, 30-day TTL, provenance, and status. hypothesis is the only writable status. Promotion to targetable requires separate owner approval. Deny-list screening runs at bridge creation, with tests proving sensitive composites (gym attendance plus meal-replacement purchase, for instance) are rejected at write time rather than filtered at read time.

5. Causal Measurement — The PROVE Loop [PARTIAL]

This is the layer that distinguishes the platform from optimization tooling.

5.1 Attribution is not causation

Last-click, first-click, linear, time-decay, and data-driven attribution all answer "which touchpoints preceded conversion?" None answers "which spend caused conversion that would not otherwise have occurred?" The second question is the only one with budget implications.

5.2 Techniques in use

Qualified holdouts — registered before activation, with power analysis, contamination checks, and outcome-integrity validation preceding the test window.

Geo holdouts — matched-market designs with owner-configured aggregate geographies, exclusions, donors, and caps.

Ghost bids [PROPOSED] — a design exists (GHOST_BID_HOLDOUT_IMPLEMENTATION_PLAN.md) for entering auctions the platform deliberately declines to win, constructing a counterfactual matched on auction dynamics rather than observable traits. This is an implementation plan, not a shipped technique, and is not claimed on any customer-facing surface.

Intention-to-treat — measured on assignment, not on delivery, so delivery failure cannot masquerade as ineffectiveness.

CATE meta-learners — S-, T-, X-, and DR-learner families estimating conditional average treatment effects, surfacing where lift concentrates rather than reporting a single blended average that describes no actual segment.

Automated refutation — every causal estimate is subjected to DoWhy refutation tests: placebo treatment, random common cause, data subset validation. An estimate that survives no refutation test is not reported as a finding.

5.3 The Causal Credit Ledger [PARTIAL]

Conversions are classified as caused or anticipated. A model that correctly predicts a purchase that would have happened anyway has demonstrated forecasting skill and contributed zero incremental revenue. Two principles are enforced in code:

Anticipation is never credit. Prediction never grades itself.

Holdout registration is mandatory before any activation. Not after, not concurrently.

6. Net Yield — The PROFIT Loop [IN BUILD]

Platform ROAS measures revenue against ad spend. It excludes payment processing, fulfillment, shipping, returns, discount liability, and cost of goods. Campaigns can therefore optimize toward negative-contribution revenue while every dashboard reports success.

Net yield modeling pulls true unit economics from commerce data (net_yield_costs.yaml) and computes contribution after all downstream costs. In v1 this runs NET_YIELD_WRITEBACK=false — recommendation only, with a test that fails the build if the flag is flipped without approval.

Missing required costs leave a row incomplete and excluded. Costs are never invented to complete a calculation.

7. Channel Automation and Execution Rails

Every adapter defaults to observe-only. Execution authority is a separate, explicitly granted permission. The system's normal posture toward a live ad account is to watch, model, and recommend.

Two writeback flags govern whether modeled outputs may leave the platform:

• MEASUREMENT_WRITEBACK — OFF. Modeled conversion signal does not flow back into platform optimization.
• NET_YIELD_WRITEBACK — OFF. The platform makes no claim to bid on net contribution.

Each requires its own verified pilot and separate approval before it can be enabled. Neither flips as a side effect of any other change.

Ad Control Plane — bandit arms and causal bidding [PROPOSED]. A designed extension of the execution rails: bandit arms are admissible only inside the tenant's declared per-decision, daily and cycle caps, only on cohorts whose holdout was registered before first exposure, only at autonomy levels L2/L3 (two-key), and only within an exploration budget the tenant declares at onboarding — an undeclared budget means no exploration. Causal bidding, which shapes a bid from the continuous-dosage estimate (τ(d*)·margin = marginal_cost), stays blocked until that estimator leaves its advisory posture through a named pilot and a human promotion decision. The pacing veto that bounds all of this is built and test-pinned, wired into the policy engine behind a flag that ships off (PACING_VETO, default off, off in production; owner ruling W3-12a, 2026-09-15) — no tenant is enforced by it today; the plane optimizes incremental return (iROAS), never platform ROAS; ghost bids remain PROPOSED; no writeback flag moves. Nothing in this paragraph is a performance claim.

Agent-originated conversions [IN BUILD]. The canonical event schema carries an origin dimension (human / agent / bot / unknown, protocol by declared header name) classified shadow-only behind a flag that ships OFF; credit outputs are never altered by it, and a governance event fires when a pilot's agent-originated share exceeds 10% (design target for the threshold; strict).

Measurement interoperability [PROPOSED]. The platform's decisions are governed by incremental ROAS measured against registered holdouts — never by a platform's own attributed ROAS. For customers who also run a marketing-mix model, the causal credit ledger can be exported into the input shapes of Meta's Robyn and Google's Meridian, with the holdout-measured incremental value supplied as the experiment-calibration input those tools already accept. The export ships dark and requires at least two closed quarters of data; no model result is claimed.

8. Decision Jobs and the Decision Control Plane [IN BUILD]

Automation is expressed as a registry of High-Value Decision Jobs (J-01 … J-06) — recurring, high-consequence questions the system answers on a cadence: budget reallocation, creative retirement, audience expansion, bid posture, inventory-aware pacing, spend suppression.

Each job runs through the Decision Control Plane, which enforces:

1. Does a ValidationPassport exist with sufficient evidence?
2. Does the DEL Score clear threshold?
3. Is the required authority granted for this action class?
4. Does any governance gate veto?

A job that fails any check produces a WITHHOLD verdict with reasoning — a documented decision not to act, which is the output the architecture is proudest of.

A DEL score never overrides a failed hard constraint. Missing evidence routes to hold, named veto, or human review. Authority is never inferred from a model score.

8.1 The Clipped-ReLU DEL Authorization Function [PROPOSED CANON — per-action-class parameterization IN BUILD — not started]

The governing specification is docs/architecture/DEL_AUTHORIZATION_FUNCTION.md (PROPOSED CANON v1.0, 2026-08-11), which governs over this summary. Its §1 defines, for every action class c:

authority_c = min(cap_c, max(0, DEL_score − threshold_c))

• Flat zero below threshold — deterministic denial. No partial execution, no probabilistic leakage. Agents (however they negotiate) only propose; the deterministic policy service authorizes. A denial routes the proposal to a human with its reasoning path and a smaller alternative — never silently dropped.
• Margin-proportional authority above threshold. A barely-cleared score earns only the smallest reversible version of the action (the ACT-991 canon, governing doc §5).
• Saturation at cap_c. The covenant cap bounds authority regardless of margin.
• Adaptive guardrail envelopes are threshold shifts under volatility — the envelope may move threshold_c up (more conservative) in turbulent regimes; it never lowers a floor.

Status, in the governing document's own words: "PROPOSED CANON v1.0 (2026-08-11) … this document becomes canon when the owner merges its review PR, and its per-action-class parameterization remains [Roadmap] until built." Its §7 build table lists the per-action-class threshold_c / cap_c registry and the margin-proportional clip in the Decision Control Plane as [IN BUILD — not started]. Floors are not configurable downward (governing doc §2): the platform-wide floor that exists today is DEL ≥ 80.0 at the Decision Control Plane; customers may raise thresholds, never lower them.

Shipped reality, in one sentence: today's DEL score is the linear weighted average 100*(0.5*passport_pass_rate + 0.3*evidence_completeness + 0.2*verification_weight) computed in services/service-policy-engine/main.py:176-178, threshold-gated and HMAC-signed at the Decision Control Plane — Feature Coverage Matrix gap G-18 ("canon describes clipped-ReLU; code implements a linear weighted average"). §14.3 is the full code-truth statement and this section defers to it on what is shipped: the threshold-gated concept (below threshold → blocked with the constraint named in the passport; above → authorized with a signed proof) is live, and the clipped-ReLU shape — margin-proportional authority and per-class saturation — is not.

Why it earns a customer-facing paragraph (design target): most autonomy systems make authority a smooth function of model confidence, which means enough confidence eventually buys any action. The clipped function makes two refusals structural — the refusal to act on thin evidence, and the refusal to exceed granted authority no matter how certain the model is. That is the design target the platform is building toward, not a description of the shipped function. Today the same two refusals are delivered by threshold and ceiling checks rather than by the function's shape: the DEL ≥ 80.0 floor and the veto battery (§14.3), and the actuator ceiling plus the action-runner's independent re-check (§14.4).

8.2 ValidationPassport [IN BUILD]

Every decision carries an evidence packet: signals used, model versions, causal estimate with refutation results, confidence bounds, consent basis, retention window, and governing rulings. An analyst can reconstruct any decision without access to the person who made it.

9. The Five Frontiers [PARTIAL — built flag-off, activation gated]

Machinery for all five frontiers was built in the 2026-08-19 completion run (independently verified; see reports/GC_COMPLETION_BUILD_2026-08-19.md). They are governed implementations, not live capabilities: configuration is intentionally null pending pilot inputs, and every activation path is gated as below.

F4 sequences before F1. F4 cannot be observe-only by nature — reserving a geography is an action — so per-action approval is its control mechanism.

10. Governance as Architecture

Governance is not a compliance chapter appended to a technical document. It is the load-bearing differentiator.

Consent gate — no consent, no persistence. Analytics-only consent rejects behavioral signal. Enforced by test matrix.

GDPR erasure cascade — deletion propagates through every table, vector, graph edge, and derived artifact. Every new field joins the cascade test suite as a condition of merge.

Creepiness deny-list — screening at inference creation, not at display. Sensitive composites are refused at write time.

Observe-only default — every capability ships flag-off. Flags off produce byte-identical serving behavior, asserted by test.

Shadow deployment — predictions write to shadow tables and are never served; bridges write as hypotheses and are never targeted; creative ranks log and never apply.

Three-level rollback — flag revert without deploy; revision revert with recorded pre-deploy revision IDs; additive-only schema changes so old events still validate.

Fleet integrity — as more merchants run on the platform they will meet in the same auctions and product categories, so independence is built in rather than promised. Each merchant's optimization loop runs on its own signals, its own net-contribution objective, and its own authorization thresholds: there is no cross-merchant bid coordination, and because every decision journals its inputs, an auditor can verify from the ledger that no decision for one merchant consumed another merchant's data [PARTIAL — test-pinned by tests/governance/test_fleet_integrity.py and the ledger independence audit in contracts/mizoki_contracts/independence_audit.py; the release-time run of that audit is not yet scheduled]. Where cold-start seeding draws on pooled category priors, those priors are differentially private aggregates, always labeled as priors, and never a merchant-level incrementality claim [IN BUILD — no pooled-prior pipeline exists today; consent default is an open owner decision]. The platform runs in a single region today; EU data residency per tenant is an owner decision with counsel before any EU merchant is onboarded [PROPOSED — owner decision D-14 open; no residency setting exists in any tenant configuration, and that absence is test-pinned so nothing can silently claim it].

10.1 Autonomy gates

Automated action requires, without exception:

• Brier score ≤ 0.20 — calibration, not accuracy
• AUC ≥ 0.72 — discrimination
• Stable lift across ≥ 2 purchase cycles — durability

A model that misses any threshold recommends. It does not act. There is no override path that bypasses these numbers.

10.2 Claim discipline as machinery

Truth discipline is enforced structurally rather than by intention: automated content QA gating in CI, status labels on every capability claim, illustrative scenario numbers labeled as such, and a public claim ledger. Preview labels flip to verified claims only after pilot numbers enter the ledger.

The governing policy is build-to-claim: when copy and capability diverge, the resolution is to build the capability. Never to soften the copy.

11. Onboarding: The 90-Day Growth Control Pilot

Standard onboarding, structured in three gates:

Gate 1 — Observe. Instrumentation, signal validation, baseline establishment. No actions taken. Gate 2 — Prove. First registered holdout. Causal estimates produced and refuted. Recommendations issued; humans execute. Gate 3 — Control. Bounded execution authority granted for action classes that have cleared autonomy gates across at least two purchase cycles.

Most platforms sell Gate 3 on day one. The sequence is the product.

12. Summary

The through-line: the system is designed to be trusted with authority it does not yet have, by demonstrating restraint with the authority it does.

13. Extended Capabilities (U1–U9)

Folded from amendment r1.3 (August 2026) with every heading, label and body unchanged. Sources: build reports through F4 go-live (2026-08-24); Completeness Audit v1.0. Nothing in this section upgrades a label.

U1 · Passport Chaining — Decision Lineage [PARTIAL]

Business purpose: answer "why did the system believe this?" not just "what did it decide?" Regulators, boards, and CFOs ask for the chain, not the node. How it works: each ValidationPassport carries references to the passports and realized outcomes that fed it, forming a traversable lineage graph over the decision store, exercised end-to-end by the SIG-042 harness. Customer benefit: a dispute, audit, or post-mortem reconstructs the full ancestry of any spend action in minutes — the audit trail becomes an audit graph.

U2 · Governed-Vertical Generalization (Counsel Room) [PARTIAL — roadmap framing only]

Business purpose: proof the decision architecture is not a marketing trick: the same Sense→…→Learn loop and gates run a legal-domain scenario lane. How it works: identical Decision Control Plane, passports, and WITHHOLD semantics over a different evidence domain. Customer benefit: enterprise buyers see an architecture, not a point tool — the governance you approve once generalizes. Presented on the About/roadmap surface, never as a marketing-product claim.

U3 · GraphRAG / CausalRAG Explanation Retrieval [PARTIAL]

Business purpose: explanations that cite structure, not vibes. How it works: retrieval over the intent/decision graph respecting causal edges; powers the explanation payloads that accompany every score — an inference the system cannot explain is not surfaced. Customer benefit: every recommendation arrives with its evidence neighborhood attached; analysts verify instead of trusting.

U4 · MarketSignal External Knowledge Graph (Cell 37 lane) [PARTIAL]

Business purpose: context without new PII — demand shifts, market events, external signals as corroboration. How it works: brownfield Cell 37 ingests external market signal joined to first-party evidence strictly as corroboration; it never substitutes for consented behavioral data and never enters causal credit on its own. Customer benefit: fewer false alarms — "your CPA rose because the market moved" is distinguishable from "because your site slowed."

U5 · Geo-SCM Scheduler — the Always-On Half of F4 [LIVE with F4]

Business purpose: continuous calibration without blackout tests. How it works: synthetic-control donor selection plus perturbation-window scheduling feed F4's approval-gated reservations; clean cycles update MMM priors, never before. Customer benefit: incrementality stays current every week at small, capped cost — no quarterly "turn it all off" experiments, no stale lift assumptions.

U6 · Stockout DEL Veto [PARTIAL]

Business purpose: inventory reality as a hard constraint, not a suggestion. How it works: stock state enters the decision-eligibility evaluation itself: a proposal to scale spend into a stockout is vetoed with the constraint named in the passport — upstream of any adapter, regardless of model confidence. Customer benefit: the embarrassing failure mode — paid traffic to sold-out SKUs — becomes structurally impossible to authorize.

U7 · Governed Build Fleet [LIVE — engineering surface]

Business purpose: credibility you cannot fake: the AI fleet that builds the platform obeys the same gates the platform sells. How it works: claim-first coordination ledger, skill parity checks, canon linter, adversarial verifiers, typed approval strings — the platform's own governance applied to its makers. Customer benefit: the vendor's development process is itself evidence of the product thesis. Documented on the engineering/About page.

U8 · Deploy-Time Canon Correction [LIVE]

Business purpose: documents cannot drift from reality. How it works: every doc pushes through content QA and canon transforms at deploy; stale technical claims are corrected or blocked — this pipeline corrected this whitepaper's own §3 datastore reference on publication. Customer benefit: what you read on our surfaces has passed the same truth gate as our code — including this amendment.

U9 · Intent Tool Surface + Deterministic Scenario Replay [PARTIAL]

Business purpose: the integration story for technical buyers. How it works: eight shipped intent tools expose evidence programmatically; demo scenarios replay deterministically — same input, same trace, same passport. Customer benefit: your engineers integrate against evidence APIs and reproduce any demonstrated behavior exactly; evaluation becomes verification.

13.1 Placement and discipline

U1, U3, U4, U5, U6, U8 are platform capabilities within this whitepaper's scope. U2, U7, U9 are credibility/integration surfaces documented on About and launch pages, referenced here for completeness. All nine carry citation markers in the Feature Coverage Matrix; no status flips outside the standard gates; anticipatory-intent framing governs throughout.

14. The Platform Under the Marketing Product

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.

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.

Citation vintage (r2.0, 2026-09-02): the file:line citations in §14.1, §14.2 and §14.4–§14.6 were carried from r1.4 (verified 2026-08-26) and re-checked against the tree on 2026-09-02 at the Wave 1 gate: three had moved and are refreshed here (src/cells/cell37/market_cell/f3_inventory.py:504 → :530, services/service-policy-engine/main.py:126 → :75, README.md:68 → :85); contracts/mizoki_contracts/treasury.py:223 still resolves. The refresh is logged against Feature Coverage Matrix §10. §14.3's citations were re-verified and refreshed in r2.0.

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:176-178) — 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:168-284). 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. The governing clipped-ReLU definition and its PROPOSED CANON status are quoted in §8.1, which defers to this section on what is shipped; the two sections describe one mechanism.

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. # MIZ OKI 3.5/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:530, 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:75), never via a graph edge. Counsel Room exists only inside the demo runtime, not as a production legal service. README.md:85 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.

All capability claims in this document carry status labels. Scenario figures elsewhere in MIZ OKI materials are labeled illustrative and are not production telemetry or customer results. Platform business targets (CAC reduction, ROAS improvement, ROI) are stated goals, not measured outcomes, and will not be presented as results until verified pilot numbers enter the claim ledger.