FFO/Applications Plane
How FFO/Applications models enterprise application twins (Oracle EBS and peers) — distinct from FFO/Platform IT twins and FFO/Facility DCIM twins.
FFO/Applications Plane
The Federal Frontier Ontology is one ontology family with many TypeDB instances. Operators and tenants run dedicated FFO/Applications instances for enterprise application twins (ERP, HCM, campus, manufacturing). Each tenant still runs FFO/Platform for IT. Operators run FFO/Facility for the datacenter. Instances join only through boundary bridges — not one shared mega-graph.
Naming (locked)
| Written | Spoken | Meaning |
|---|---|---|
| FFO/Applications | Applications FFO | Enterprise application twin plane |
| FFO/Applications:<app-or-tenant> | X’s Applications FFO | A specific application or tenant Applications instance |
| FFO/Platform | Platform FFO | Per-tenant Federal Frontier Platform IT twin |
| FFO/Facility | Facility FFO | Operator datacenter / DCIM twin |
Prefer Applications for the ERP/app plane. Do not fold Oracle EBS (or peers) into the Platform IT graph.
Why an Applications plane?
Platform FFO models clusters, nodes, workloads, and related IT. Facility FFO models site → room → rack → asset. Agencies and enterprises also need a first-class twin for running enterprise applications:
- Agents need app-native context (EBS concurrent managers, workflows, modules, app↔DB↔middleware topology) without stuffing ERP entities into the IT graph.
- Oracle E-Business Suite is the poster child (Vision for lab/demo). PeopleSoft, JD Edwards, and similar ERPs follow the same plane pattern.
- The live ERP (database + apps tier) remains the System of Record for application configuration and transactional truth.
- FFO/Applications is the agent- and ops-facing graph — not a second ERP and not Oracle Enterprise Manager.
Systems that feed Applications FFO
| System | Role |
|---|---|
| Oracle E-Business Suite (e.g. Vision lab) | Application SoR — financials, procurement, HR, concurrent processing, workflows |
| Oracle Database (EBS DB tier) | Data tier SoR; AWR / sessions / tablespace health via DB MCP |
| WebLogic / apps tier | Middleware hosting EBS services |
| oracle-ebs-mcp / oracle-db-mcp (planned) | Read (then gated write) tools for concurrent managers, workflows, DB health |
| HyperSync-style projectors (future) | Scheduled reconcile from app/DB catalog → Applications FFO |
| FFO/Platform instances | Host VMs, K8s, storage — linked only via boundary bridges |
| FFO/Facility | Physical placement of app hosts — linked only via boundary bridges |
See Applications Ownership & Data Flow for the ownership matrix and MVP phasing.
What Applications FFO is not
- Not the Platform IT twin. Clusters, nodes, pods, and Ceph stay in FFO/Platform.
- Not the Facility / DCIM twin. Racks and sensors stay in FFO/Facility.
- Not a second ERP. It does not replace EBS, PeopleSoft, or JDE.
- Not OEM / support-contract telemetry. Oracle Workload MCP and the twin exist so ops intelligence works without requiring Oracle support contracts (Rimini + FFP pitch).
- Not a dump of every transactional row. Model topology, health, modules, and ops entities agents need — not the full AP invoice ledger.
Relationship to other planes
FFO/Facility ──bridge──► hosts / placement
FFO/Platform ──bridge──► VMs, clusters, storage for the app stack
FFO/Applications ◄── ERP SoR + MCP / projectors
The published Schema Reference documents Platform-oriented modules. Applications adds ERP/app entity types in the Applications instance. Exact TypeQL names land with the applications schema work; treat this page as the plane contract, not the full schema dump.