CRE Prospecting Integration — Phase 0 Discovery Report

Date: 2026-08-16 Phase: P0 (read-only discovery, no code) Claim: CRE prospecting engine — cells 38/39, outreach authoring, cre-prospecting-virtuoso skill

1. Cell Registry — Ground Truth

Source: docs/architecture/CELL_REGISTRY.md (the number authority, owner ruling 2026-08-11)

• Current count: 37 registered cells (32 production + 4 LII + 1 gateway)
• Constitution preamble: says "37 registered cells total" (patched from 36→37, owner-directed 2026-08-13)
• Next free indices: 38 and 39 — confirmed by grep; no reference to cell38/cell39 exists anywhere in the repo

The Boss runtime directory holds 45 alias keys for these 37 cells — deduplication matters (raw key count ≠ cell count).

Proposed assignments

The split is at the DECIDE boundary: Cell 38 never touches a recipient; Cell 39 never computes a match.

Article VI impact

Patching the cell count from 37→39 is an Article VI owner item (CONSTITUTION.md VI.1: "Only an explicit directive from the repository owner amends this set"). Precedent: the 36→37 patch was explicitly documented as an Article VI owner item in CELL_REGISTRY.md:12. The patch must land with same-commit coherence (VI.2): miz_oki_source_of_truth.py updated, check_conformance() → zero violations, skillpack re-synced, both virtuoso_models homes byte-identical.

These files are NOT in the auto-merge protected path set (.github/, deployment/terraform/, deployment/cloudbuild*, CODEOWNERS), so a branch on an auto-merge prefix could technically land them without human review. However, Article VI governance binds regardless of the merge path — a human PR is the correct vehicle.

2. Existing CRE Domain Infrastructure

The CRE domain is already a first-class governed domain in MIZ OKI 3.5. This is a significant finding — the new prospecting cells compose with existing infrastructure rather than creating it from scratch.

2.1 Governed domain registration

src/shared/miz_oki_source_of_truth.py: - DOMAINS = ("finance", "media", "cre", "counsel", "estate", "risk") — CRE is one of six governed domains - CRE has a NON_BYPASSABLE gate: SimulationPassport with baselines mandatory, BenchmarkProgram phase locks, human-authority requirements - CRE model registry thresholds: extraction precision ≥ 0.95, recall ≥ 0.93, NOI MAPE ≤ 0.12, copula df stability ≥ 60 rows - CRE regulatory anchors: FIRREA/USPAP, SR 11-7/OCC 2021-39, ASTM E1527-21, PE licensing, ECOA/Reg B - advisory_only=True with a defined lift path (real benchmark corpus + named human approver)

2.2 Constitution bindings

• Article II.1: CRE has SimulationPassport with mandatory Gaussian and historical-bootstrap baselines; benchmark phases unlock sequentially; binding valuation/engineering/environmental/credit decisions remain with licensed human authorities
• Article II.3: cre/binding_commitment is FORBIDDEN_AUTONOMY — never enters autonomy; a grant raises and cannot be configured around
• Article II.4: CRE is advisory_only=True, with a defined lift path to non-advisory (same as finance)

2.3 Existing code — src/shared/mizoki_cre/

Byte-identical twin: miz_oki_3.5_integrated/mizoki_cre/ (same 4 files)

Key insight: The existing mizoki_cre module is about underwriting & asset risk intelligence — Monte Carlo simulation, NOI validation chain, deal-level analysis. It does NOT contain any prospecting, outreach, tenant-matching, geocoding, or email-authoring code. The new cells (38/39) complement it: Cell 38 identifies which properties and tenants are worth analyzing; the existing mizoki_cre module then evaluates the deals they represent.

2.4 Virtuoso model routing

miz_oki_source_of_truth.py already routes CRE calls through virtuoso_call: - ("cre", Phase.REASON) → DATA_CAUSAL - ("cre", Phase.PLAN) → DATA_CAUSAL - ("cre", "document_extraction") → DATA_CAUSAL (lease/rent-roll abstraction)

The prospecting cells will need new routing entries for their specific phases (e.g., entity resolution, scoring, outreach authoring).

3. Existing Skills Inventory

CRE-specific skills: NONE

No CRE-specific skill exists in either skills/ or .claude/skills/. Existing skill names: - miz-oki-platform-expert, adwords-virtuoso, programmatic-media-acquisition, meta-programmatic-acquisition, media-acquisition-virtuoso, enterprise-virtuoso, investor-virtuoso, ontology-kg-virtuoso, ga4-expert, html-virtuoso, creative-development-deployment, american-legal-system, email-deployment-ip-warmup

Composable skills

The enterprise-virtuoso has a Prospect concept and routing for property/real-estate questions. Its profile_registry.yaml lists virtuoso profiles; none is CRE-specific.

The proposed cre-prospecting-virtuoso skill would be new and must not shadow: - enterprise-virtuoso (general business intelligence) - investor-virtuoso (investor relations and financial modeling) - media-acquisition-virtuoso (media buying — different "acquisition")

4. Connector Inventory

Configured/Built

Required for CRE Prospecting — NOT configured

No code references to any of these connectors exist anywhere in services/, connectors/, or src/.

Connector governance

All new connectors must follow the connector governance pattern established for Shopify (marketing-commerce-connectors.md rule): - One governed ingress through canonical ingestion - No direct connector-to-KG/datastore side doors - Provider-native evidence retained - Tenant, consent, idempotency, replay, reconciliation, and lineage controls

For CRE prospecting, the consent model differs from e-commerce: CRE data subjects are commercial entities (businesses, property owners, brokers), not consumers — but the platform's consent-fail-closed gate still applies at the person level for contact data.

5. Ontology Baseline

Current state

• Registry: ontology/registry.yaml v1.1.0, machine-validated baseline
• Layers: foundational (classes, relationships, constraints), enterprise (concepts)
• Domain modules: planned but not materialized — marketing, advertising, media, ecommerce, customer, product, finance, operations, risk, compliance. No CRE domain module exists.
• Prospect concept: defined in enterprise/concepts.yaml as "A potential customer role prior to first purchase" — subclass of Role

Concepts the CRE cells will need (candidates for an OCP)

The following concepts are absent from the ontology and would require an Ontology Change Proposal:

Architecture-level (requires owner approval): - Property — a physical real estate asset (new top-level class under Entity) - Lease — a binding agreement for space (specializes Contract)

Steward-level (requires steward approval): - Submarket — a geographic commercial real estate market area - PropertyType — enumeration (office, retail, industrial, multifamily, mixed-use) - TenantProspect — a Prospect specialized for CRE tenant matching - Flyer / MarketingFlyer — a property marketing document (specializes DigitalObject) - ProspectingCampaign — a coordinated outreach activity (specializes Campaign)

OCP mechanics

OCP template: ontology/proposals/TEMPLATE.md. Three existing OCPs: 1. OCP-20260806-001.md 2. OCP-20260811-amazon-taxonomy-import.md 3. OCP-20260811-external-entity-spine.md

Self-approval of steward/architecture OCPs is forbidden (registry.yaml:110). Approval ladder has ceo@mediaintelligence.ai appointed at both steward and architecture levels.

6. Coordination Mechanism

The coordination mechanism is scripts/claude_memory.py record --tags coordination:

usage: claude_memory.py record --title TITLE --summary SUMMARY
                               [--status {blocked,configured,...}]
                               [--tags TAGS] [--evidence EVIDENCE]

Multi-session coordination rules (.claude/rules/02-multi-session-coordination.md): - Claim the capability, not just the paths - Read newest coordination-tagged entries first - If the claim collides with a live one, settle it before writing code - Large/cross-cutting work belongs on a branch outside auto-merge prefixes, behind a human-merge PR

7. Governance Requirements Summary

For the Article VI cell-count patch (37→39)

1. Owner directive required (Article VI.1)
2. Same-commit coherence (Article VI.2): - CONSTITUTION.md preamble: update "37 registered cells" → "39 registered cells" - docs/architecture/CELL_REGISTRY.md: add Cell 38 and Cell 39 rows - src/shared/miz_oki_source_of_truth.py: version bump, add CRE prospecting domain entries - miz_oki_3.5_integrated/: byte-identical twin updated - production/service-registry.yaml: add cell38/cell39 entries - check_conformance() → zero violations - Skillpack re-sync via scripts/skills_sync.py --fix - canon.lock.json re-pin if any canon-surface changes
3. Human PR (not auto-merge) for the registry/constitution patch
4. Versioning (Article VI.3): new cells within existing articles = minor version bump

For the ontology changes

1. One or more OCPs in ontology/proposals/
2. Architecture-level OCP for new top-level class (Property) requires owner approval
3. Steward-level OCPs for new subclasses/properties

For new connectors

1. Each connector follows the connector governance pattern
2. New connector types need connector-credential management (connector_credentials.py in the gateway)
3. Person-level contact data (from Apollo/Hunter) triggers consent-fail-closed gate

8. Blockers and Surprises

Surprises (positive)

1. The CRE domain is already fully governed. The existing mizoki_cre module provides the underwriting/simulation infrastructure that Cell 38's scoring output feeds into. This was not assumed — the original spec treated CRE as entirely greenfield.
2. Prospect concept already exists in the ontology enterprise layer. The CRE tenant prospect can specialize it.
3. Virtuoso model routing for CRE already exists — ("cre", Phase.REASON) and ("cre", Phase.PLAN) are registered.

Blockers

1. Article VI owner directive is required before the cell-count patch can land. No code depends on this for P1-P3, but the cells cannot be registered without it.
2. Zero CRE connectors exist. Apollo, Hunter, Google Maps/Geocoding, Pipedrive, Microsoft Graph, CoStar, and LoopNet all need to be built from scratch. This is the largest lift in the integration.
3. Contact data governance. Person-level enrichment data (from Apollo/Hunter) must clear the consent gate. The existing CRE module operates on property/deal data, not person data — the prospecting cells introduce a new data subject category (commercial contacts) that must be mapped to consent requirements. The creepiness deny-list (Article II.8) and person-level entity-spine restriction (entity-spine scope: organizations, brands, products, campaigns — not persons) are relevant constraints.
4. Ontology domain module. CRE has no domain ontology module yet (the domain modules are all "planned"). The architecture-level OCP for a Property class needs owner approval.
5. No existing deploy path for new cells. New cells would follow the dispatch-only pattern established for Cells 33-37 (no push trigger, human-dispatched deploy), which requires a new deploy-cre-prospecting.yml workflow in .github/workflows/.

Items that are NOT blockers

• The auto-merge protected-path gate does NOT cover CONSTITUTION.md or CELL_REGISTRY.md — but Article VI governance binds regardless. Use a human PR as the correct vehicle.
• The existing mizoki_cre module does not need modification for P1. The prospecting cells compose alongside it.

9. Phase Summary

Report generated 2026-08-16 as Phase 0 of the CRE Prospecting Integration. No code was written. Next phase (P1) produces the Article VI patch, ontology OCPs, and skill skeleton.