Intelligence Cells — Engineering Model

Platform: MIZ OKI 3.5
Canonical loop: SENSE → REASON → PLAN → VALIDATE → DECIDE → ACT → LEARN

1. Definition

An Intelligence Cell is a governed operating unit that converts a source, domain, model, or service into a participant in the MIZ OKI 3.5 decision loop.

A connector only moves data. An Intelligence Cell must also provide structure, provenance, evaluation, graph mapping, decision support, auditability, and learning behavior.

2. Minimum cell contract

Every Intelligence Cell should declare the following contract.

3. Lifecycle

flowchart LR
    Draft[Draft cell contract] --> Observe[Observe-only sensing]
    Observe --> Recommend[Recommend-only planning]
    Recommend --> Validate[Evaluation harness]
    Validate --> Approval[Human approval mode]
    Approval --> Controlled[Controlled execution]
    Controlled --> Learn[Outcome learning]
    Learn --> Registry[Registry update]

1. Draft cell contract: define source contract, canonical event mapping, graph mapping, evaluation gates, and autonomy boundary.
2. Observe-only sensing: ingest data and write canonical events without recommending or acting.
3. Recommend-only planning: generate recommendations but block external changes.
4. Evaluation harness: run schema, freshness, policy, financial, causal, and regression tests.
5. Human approval mode: allow actions only when an authorized human approves.
6. Controlled execution: enable limited execution with idempotency, pre-state, post-state, rollback handle, and audit logging.
7. Outcome learning: compare predicted and actual results; update KG, policies, confidence, and future recommendations.

4. Intelligence Cell examples

4.1 Google Ads GAQL Intelligence Cell

4.2 OpenRTB Bidstream Intelligence Cell

4.3 ESP/Webhook Intelligence Cell

4.4 Legal/Advertising/Policy Intelligence Cell

4.5 Creative Intelligence Cell

4.6 Financial/Performance Intelligence Cell

5. Canonical event mapping rules

1. Never drop raw payload lineage.
2. Always emit schema_version.
3. Preserve source IDs and source timestamps.
4. Store deterministic and probabilistic match evidence separately.
5. Represent validation failures as events or evidence records.
6. Keep action events separate from source facts.
7. Record whether an event is observed, inferred, simulated, or human-entered.

6. Registry design

A minimal registry entry should look like this:

cell_id: cell.google_ads_gaql
name: Google Ads GAQL Intelligence Cell
domain: advertising
status: planned
primary_srpvdal_role: SENSE
secondary_roles: [REASON, PLAN, VALIDATE, DECIDE, ACT, LEARN]
autonomy_default: recommend_only
action_permissions:
  - observe
  - recommend
  - mutate_with_policy_approval
canonical_events:
  - GoogleAdsCampaignEvent
  - GoogleAdsSearchTermEvent
  - GoogleAdsConversionEvent
evaluation_gates:
  - source_schema_validation
  - gaql_compatibility
  - financial_guardrail
  - policy_approval
audit_outputs:
  - raw_payload_hash
  - query_hash
  - decision_trace_id
  - approval_record_id

7. Acceptance criteria for a production-ready cell

A cell is production-ready only when it has:

• documented source contract;
• canonical event schemas;
• KG node and edge mapping tests;
• schema drift detection;
• source health endpoint or report;
• error and retry behavior;
• provenance and audit records;
• evaluation gates;
• approval behavior;
• dry-run mode;
• rollback or compensating action plan;
• outcome learning record;
• owner and operational runbook.

8. Immediate engineering tasks

1. Create the central cell registry.
2. Backfill current services into the registry with honest status labels.
3. Promote only cells that pass evaluation harnesses.
4. Mark dry-run and placeholder endpoints explicitly.
5. Add canonical schemas before adding new source-specific logic.
6. Add decision/outcome learning records to close the loop.