MIZ OKI 3.5 Architecture Reference

Canonical platform: MIZ OKI 3.5 — Operating Knowledge Intelligence
Canonical loop: SENSE → REASON → PLAN → VALIDATE → DECIDE → ACT → LEARN
Purpose: Ground engineering, product, demo, and investor discussions in the same architecture.

1. Architecture thesis

MIZ OKI 3.5 is an autonomous decision intelligence operating system. Its purpose is to convert source data into governed operating knowledge, reason over that knowledge, propose actions, validate them, select the best approved option, execute safely, and learn from outcomes.

The platform should be understood as a control plane, not as a reporting layer. Reports and dashboards are views into the system; the operating system is the seven-stage SRPVDAL loop plus the graph, evaluation, approval, execution, and learning infrastructure behind it.

2. Core layers

flowchart TB
    A[Source systems] --> B[Canonical event layer]
    B --> C[Operating Knowledge Graph]
    C --> D[Reasoning + planning]
    D --> E[Evaluation + governance]
    E --> F[Decision control plane]
    F --> G[Controlled execution]
    G --> H[Outcome learning]
    H --> C

2.1 Source systems

Source systems include APIs, webhooks, files, streams, operational databases, analytics warehouses, advertising platforms, commerce systems, creative systems, legal/policy documents, finance systems, and internal services.

2.2 Canonical event layer

The canonical event layer normalizes raw records into versioned events with source provenance, match keys, schema metadata, transformation lineage, and validation status. This layer prevents raw platform data from becoming operating truth without structure.

2.3 Operating Knowledge Graph

The graph stores entities, relationships, evidence, policies, decisions, plans, actions, and outcomes. It is the memory substrate for reasoning and governance.

2.4 Reasoning and planning

Reasoning combines graph traversal, retrieval, temporal context, causal evidence, prior decisions, and agent outputs. Planning turns that reasoning into candidate actions and alternatives.

2.5 Evaluation and governance

Validation gates decide whether a plan is good enough to become a decision candidate. Gates include data quality, connector health, policy, legal, brand, financial, statistical, causal, operational, and approval checks.

2.6 Decision control plane

The decision control plane ranks validated options, explains the selection, captures rejected alternatives, and decides whether the action can be executed automatically, requires human approval, should be deferred, or must be blocked.

2.7 Controlled execution and learning

Execution must be idempotent, audited, reversible where possible, and tied to a pre-state and post-state. Learning compares predicted and observed outcomes, then updates graph memory, confidence, and future recommendations.

3. Repository-grounded architecture

4. SRPVDAL reference architecture

SENSE

Purpose: Capture and normalize source signals.

Inputs: API rows, webhook events, files, streams, internal service outputs, and raw source payloads.

Outputs: canonical events, source health status, match keys, provenance records, and validation errors.

Engineering requirements: preserve raw payloads or durable pointers, version every source contract, validate schema and freshness, carry consent metadata where relevant, and emit event counts, error counts, and retry state.

REASON

Purpose: Understand what is happening and why.

Inputs: canonical events, knowledge graph context, metrics, documents, prior decisions, and outcome traces.

Outputs: drivers, hypotheses, graph paths, causal candidates, and explanation evidence.

Engineering requirements: separate correlation from causal evidence, keep evidence links on outputs, surface contradictions and stale evidence, and combine graph, retrieval, temporal, and causal context.

PLAN

Purpose: Generate action candidates.

Inputs: reasoned context, objectives, constraints, policies, and available tools.

Outputs: candidate plans, no-action baseline, expected effect, execution requirements, and rollback requirements.

Engineering requirements: generate multiple options where possible, include a no-action baseline, capture approval/risk level, and draft execution payloads without changing external systems.

VALIDATE

Purpose: Challenge plans before decision.

Inputs: candidate plans, policies, legal/brand rules, financial limits, statistical and causal evidence, and operational constraints.

Outputs: pass/block/defer results, violations, modified candidates, required approvals, and evidence quality summary.

Engineering requirements: fail closed for missing required evidence, make violations explicit, keep validation results auditable, and require review for high-risk changes.

DECIDE

Purpose: Select the best validated option.

Inputs: validated candidates, expected value, confidence, risk, approval state, and strategic objective.

Outputs: selected action, rejected alternatives, confidence score, explanation, approval, or escalation path.

Engineering requirements: record why the chosen option beat alternatives, why blocked options failed, preserve trace IDs, and separate recommendation from execution authorization.

ACT

Purpose: Execute only approved actions.

Inputs: selected action, approval token or policy authorization, pre-state, idempotency key, and execution payload.

Outputs: execution record, post-state, rollback handle, audit entry, error, or retry state.

Engineering requirements: capture pre-state before changes, make execution idempotent, respect API limits, verify post-state, and prefer dry-run or approval mode until a cell has passed gates.

LEARN

Purpose: Improve future decisions.

Inputs: execution record, observed outcome, prediction, counterfactual or baseline, and human feedback.

Outputs: learning record, updated KG evidence, updated confidence, drift or regression alerts, and future policy/model recommendations.

Engineering requirements: compare predicted vs actual results, store calibration metrics, detect drift, update memory without hiding failures, and feed learning back into KG, policies, and planning.

5. Knowledge graph contract

The Operating Knowledge Graph should include:

Relationship classes should include DERIVED_FROM, EVIDENCED_BY, TARGETS, AFFECTS, VALIDATED_BY, BLOCKED_BY, APPROVED_BY, EXECUTED_BY, RESULTED_IN, and LEARNED_FROM.

6. Self-healing graph behavior

Self-healing graph behavior should not be described as magic. It should be implemented as explicit mechanisms:

• duplicate entity detection;
• conflicting evidence detection;
• stale evidence decay;
• confidence recalculation;
• schema drift detection;
• provenance repair;
• orphan edge detection;
• rollback and supersession relationships;
• human review queues for low-confidence merges;
• regression tests for mappings and graph invariants.

The repository already contains graph memory patterns and KG deployment artifacts. The complete 3.5 self-healing contract should be formalized through schemas, tests, and registry entries.

7. Deployment view

Deployment should be service-specific.

8. Active gaps to close

1. Standardize validate naming across code paths that still use verify.
2. Add canonical event schema files.
3. Add Intelligence Cell registry and lifecycle metadata.
4. Add connector health/evaluation reports as first-class artifacts.
5. Add KG mapping tests for each canonical event type.
6. Add approval and rollback records to every external change path.
7. Add outcome learning records that can be queried from the Command Center.
8. Clean up historical docs and component READMEs so active docs no longer conflict with this architecture.

9. Architectural principle

MIZ OKI 3.5 should always answer the same operating question:

What do we know, why do we believe it, what can we do, is it safe to do it, who approved it, what happened, and what did we learn?