Applications Ownership & Data Flow

Ownership matrix and data flow for Oracle EBS (and peer ERPs), MCP tools, and FFO/Applications — including MVP phasing and conflict rules.

Applications Ownership & Data Flow

This page is the operational contract for who writes what into FFO/Applications, and how that relates to the live ERP (starting with Oracle E-Business Suite) as System of Record.

Ownership matrix

Concern ERP / EBS (SoR) DB / middleware oracle-*-mcp FFO/Applications
Module / responsibility setup, users, concurrent programs Authoritative Supports Reads / may propose Twin copy + provenance
Concurrent manager & request status Live in EBS tables — Primary ops read path Cached / projected state for agents
Workflow errors / item status Live in WF tables — Read / gated retry Twin links for blast-radius
DB health (sessions, tablespace, AWR) — Authoritative oracle-db-mcp Linked DB CI + findings
Host / cluster / storage under the app Out of scope Out of scope Out of scope Bridge ids only → FFO/Platform
Rack / power / facility placement Out of scope Out of scope Out of scope Bridge ids only → FFO/Facility

Data flow

Oracle EBS (Vision / prod) + DB + WebLogic
        │
        │  oracle-ebs-mcp / oracle-db-mcp (read-first)
        │  optional HyperSync-style projector (later)
        ▼
   FFO/Applications (TypeDB)
        │
        ├── boundary bridges ──► FFO/Platform:<tenant>
        └── boundary bridges ──► FFO/Facility

Optional later path: SoR proposals / gated write-backs (restart concurrent manager, kill session, retry workflow) always through Warrant / HIL — never silent ERP mutation from the twin alone.

Design principles

  1. SoR stays SoR. EBS (and peer ERPs) remain authoritative for application configuration and transactional systems of record.
  2. Twin is for agents and cross-plane reasoning. OutpostAI / AppAI query FFO/Applications, then call MCP for live checks.
  3. Complement Platform and Facility. Placement and infra stay in their planes; Applications holds app-native topology and ops state.
  4. Provenance on every write. Carry source (MCP, projector, manual), external ids (SID, request_id, item_key), and timestamps.
  5. Boundary isolation. Never merge Applications entities into Platform or Facility graphs; use bridges only.

MVP phasing

Phase Focus
P0 — Twin-first Applications plane contract + TypeQL starter schema (Application, AppInstance, AppComponent, EBS-oriented subtypes) + Compass/docs wiring
P1 — Read MCP / enrichment oracle-db-mcp + oracle-ebs-mcp (read-only) populate / refresh twin entities; Vision (or other lab EBS) as the test SoR
P2 — Gated actions + sync Warrant/HIL write tools; optional HyperSync-style reconcile; SoR proposals without assuming write-back success

Conflict policy (summary)

  • If live EBS/DB and the twin disagree on SoR-owned attributes, live SoR / MCP read wins after refresh.
  • Agent annotations and correlation edges (finding ↔ concurrent request ↔ VM) remain twin-authored unless explicitly mapped back to the ERP.
  • Never merge Applications, Platform, and Facility graphs; use boundary bridges only.