OntoL Ontology: Executable Blueprint for Business-Finance Single Source of Truth

Document Overview

This implementation document converts the design vision from the slide deck Business-Finance Single Account — Single Source of Truth in the Digital World into an executable blueprint for the OntoL ontology product. It serves both as a modeling standard for modelers and a phased rollout roadmap for the implementation team, answering three questions: what to build (five-layer architecture and acceptance criteria), how to build (ontology meta-model, core object catalog, link and action specifications), and in what order (four-phase roadmap with governance metrics).

Target Audiences

Implementation team — full document, focus on chapters 3, 4, 10

Product managers — chapters 2, 4, 5, 7, 12

Data engineers — chapters 3 (L1/L2), 6, 8, 11

Future AI Agents — chapters 4, 8, 9 (object, action schema, write-back mechanisms are machine-readable specs)

Relationship to Slides

The slides represent the vision and philosophy (Why & What); this document is the implementation blueprint (How). Every slogan from the slides (one number, one chain, one gate, one sandbox) maps to concrete architectural anchors, build actions, and acceptance metrics. No new system names or conflicting content are introduced; details not covered in the slides (e.g., field types) are given as suggested specifications marked "suggested".

Glossary

Ontology — Business semantic layer where objects, relations, and actions live on the same tree; the unique semantic foundation where business and finance share the same origin, residing at L3.

Object — Digital instance of a real-world business entity (e.g., a SKU, a purchase order, a store) with attributes, state, and changeable via actions.

Property — Structured fields carried by an object, including both business and finance attributes (same origin).

Link — Relationships between objects; the backbone of the ontology. "BI's backbone is metrics; ontology's backbone is object relationships — metrics fight, objects don't."

Action — Controlled state change of an object, requiring schema, pre-validation, approval, write-back, and audit trail.

Metric — Calculation definition defined once at the semantic layer (L4) and effective everywhere; pages must not write their own calculations.

Caliber — Metric's data definition (numerator/denominator, time window, filters); changes must follow a process.

Lineage — End-to-end hop-by-hop chain from source document/table → processing → metric → page, queryable at column level.

Gate — Hard budget constraint control point: order placement triggers quota check, excess goes to approval, approval triggers immediate deduction.

Scene — Data-driven (not code) page station connected to the foundation via four-step wiring; e.g., merchandise planning, procurement desk, accounts payable.

SSOT (Single Source of Truth) — Metrics defined once, shared across platforms; sales, finance, supply chain use the same number.

Birth Certificate — Metadata attached to every table/number: source systems, arrival time, processing steps.

Reconciliation Card — Caliber declaration ⊕ system-measured evidence comparison; green light only when they match exactly.

Receipt — Audit record of decisions and actions within the system.

Design Principles

Each principle includes a "landing meaning" — concrete design decisions the implementation team must make in the ontology and systems.

Single Source of Truth (SSOT) — From "numbers fight" to "one number". Any metric defined only once in L4 metric dictionary; page data retrieval driven solely by registry, no hard-coded logic; reconciliation is a system obligation, not human work. New data needs: check dictionary first, if absent then define then publish.

Traceable by Design — From "decisions lack basis". Every number has a birth certificate, every decision has a receipt; lineage registered hop-by-hop at L2 build time, no "retroactive lineage"; AIP queries only traverse fact layer, referenced objects are clickable.

Shift Control Upstream — From "budget uncontrollable". Budget validation embedded in order action's pre-check, intercepting before commitment, not explaining after month-end; approval triggers immediate deduction, no end-of-month catch-up.

Simulate Before Commit — From "one sandbox". Major commitments (store opening plans, category structure changes) first re-calculated in counterfactual simulation; deviation monitoring beyond threshold auto-triggers actions; move trial-and-error into sandbox, not real world.

Unbounded Scenes · One Ontology — From "unlimited scene extensions". Scene count unlimited (15+ stations extensible), but all scenes must connect via four-step wiring to ontology, driven by registry; data associations and semantics exist in one place only, no private data copies per scene.

Scenes Are Data, Not Code — New scene = registry registration + dataset wiring + edge table write + registry-driven retrieval, zero new code; scene flip-side is evidence chain, fully auto-generated, zero hand-written.

AI-Native — Objects, relations, actions inherently machine-readable; actions have schema, guardrails, approvals; human-AI permissions and receipts live on the foundation, not in prompts.

Write-Back Closes the Loop — Data doesn't end at "analysis", it closes at "action". Action write-back updates object state, triggers downstream updates, flywheel turns again.

Business and Finance Same Origin — Same business action (e.g., procurement receipt) simultaneously produces business state change and finance consequence record on the object model; both derive from same fact, no two separate ledgers.

Five-Layer Architecture Implementation Specs (L1–L5)

Pyramid principle: a hundred systems at the bottom, only one tree at the top. Data converges upward into a single number.

L1 Heterogeneous Systems Layer

Responsibility : Host existing business systems; no transformation, only integration.

Build Content : Inventory connected systems — MES, ERP, PLM, WMS, POS, SRM, OA, Finance Accounting; register connection method, data availability window, owner for each.

Acceptance : 100% systems registered; each has clear owner and connection record.

L2 Data Integration Layer

Responsibility : Ingest · Cleanse · Contract · Every table carries birth certificate; establish single retrieval path (chain).

Build Content :

Column-level lineage: hop-by-hop mapping registration, breakage detectable.

Birth certificate: each table registers source metadata (see Chapter 6).

Dataset versioning: each processing run produces new version, traceable.

Pipeline cleansing: multi-source heterogeneous ingestion, pipeline cleansing, output clean, trusted, traceable datasets.

Access contract: each source system signs contract before integration (schema, frequency, caliber notes).

Acceptance : Path "source doc → processing → metric → page" fully queryable, no manual copying, no second truth; any dataset can produce birth certificate; breakage auto-alerts.

L3 Ontology Layer (Core, Detailed)

Responsibility : Semantic foundation of SSOT. Objects · Relations · Actions · Business-finance same origin.

Build Content :

Humans and AI read the same ontology (modeling: unique business semantics).

Object state driven solely by actions, actions fully audited.

Business and finance on same tree: products, orders, stores, budgets know each other — one ontology for both, not two jargons (implemented at L3).

Model per Chapter 4 meta-model: object types, properties, link types, actions.

Acceptance :

Ontology schema machine-readable (shared by Agents and pages).

Business action and finance consequence same-origin verifiable (same action triggers business state and finance record from same fact).

Any finance number traceable via object links to business source doc (e.g., P&L line item → sales order → POS source doc).

Core object catalog (Chapter 4) fully modeled and connected to real data.

L4 Semantic Layer

Responsibility : Metric dictionary + business rule library + caliber changes follow process.

Build Content : Unified metric definitions (canon); unified business rules (canon); metrics defined once, effective everywhere; caliber changes follow process, pages never write own numbers.

Acceptance : 100% metrics from dictionary; rules collected, statused, owned, all in library not scattered in heads or chat logs; caliber changes leave before/after auditable records.

L5 Decision Application Layer

Responsibility : Pages · Alerts · Simulation · Gates.

Build Content : Scene stations (four-step wiring), budget gates (four-step flow), sandbox simulation (counterfactual), automated reconciliation (exact match green light), living DuPont tree (year/quarter/month three-level drill, baseline = last year same window × growth rate).

Acceptance : Page retrieval 100% registry-driven; reconciliation green light as norm; gate interception verifiable; simulation re-calculable and writes back actions.

Ontology Model Design (Core)

Meta-Model: Four Elements Definition & Constraints

Object — Business entity digital instance with type, primary key, state machine. Constraints: unique ID, object type, creation source (birth certificate), current state required; forbidden to copy object data on page side outside ontology.

Property — Object's structured fields. Three categories: business (e.g., order qty), finance (e.g., order amount, derived same-origin from business), governance (owner, status, update time). Must be registered in object type schema. Suggested types: identifiers as string, amounts as high-precision fixed-point (DECIMAL(18,4)), time as ISO 8601 UTC.

Link — Directed relationship between objects. Must have type (see 4.3 link type table), direction, cardinality (1:1 / 1:N / N:M). Links may carry edge properties (e.g., scene-type edge for scene wiring); links are queryable and verifiable ("relations queryable and verifiable").

Action — Controlled object state change. Must have schema (see 4.4); action is the only legal path to change object state; bypass writes prohibited.

Four-element synergy: Data integration (L2) populates object properties → Links weave objects into single tree → Actions change object state → State changes (write-back) trigger downstream updates, forming flywheel.

Core Object Catalog (Women's Apparel Industry)

Modeling order follows business main chain: Product → Procurement → Warehousing → Sales → Finance → Governance objects. "Business side / Finance side" columns reflect "business action and finance consequence same origin".

Key objects include:

Product/SKU — Minimum sellable unit (style-color-size). Attributes: style code, category, color, size, tag price, cost price, launch wave, status (planning→on-sale→clearance). Links: belongs to category; supplied by supplier; consumes/occupies inventory; sold via sales order lines. Actions: launch, price change, discontinue clearance. Business: launch/price change ↔ Finance: tag price & selling price baseline, cost pricing basis.

Category — Product management dimension (gate dimension). Attributes: category code, name, budget ownership. Links: contains SKUs; carries budget subject (category × delivery period gate). Actions: budget allocation, structure optimization. Business: category structure ↔ Finance: category budget & gross margin composition.

Store — Sales terminal (online/offline per enterprise). Attributes: store code, type, region, status (prep→operating→closed). Links: belongs to region/org; generates sales orders; holds inventory; simulated as sandbox variable. Actions: open, close, adjust. Business: store opening plan ↔ Finance: store investment & revenue budget (sandbox: +30 stores → sales/cost/profit recalc).

Supplier — Procurement & cooperation counterpart. Attributes: supplier code, grade, settlement method, payment terms. Links: supplies SKUs; undertakes purchase orders; settled via accounts payable. Actions: admission, rating, settlement. Business: supply records ↔ Finance: accounts payable & settlement.

Purchase Order — Commitment to supplier (gate trigger point). Attributes: order no, supplier, SKU lines, qty, amount, delivery period, status (draft→submitted→approved→placed→received→settled). Links: belongs to supplier; contains SKUs; validates budget subject (gate); generates receipt note. Actions: submit, approve, place, receive, settle. Business: place order = commitment ↔ Finance: order placement hits quota → immediate budget validation (gate step 1) ; receipt → payable confirmation; settlement → payable write-off.

Sales Order / Retail Ticket — Store/channel sales fact. Attributes: order no, store, SKU lines, qty, actual amount, time, channel. Links: generated at store; contains SKUs; contributes to metric (actual sales); consumes inventory. Actions: entry (POS auto), return reversal. Business: actual sales ↔ Finance: revenue recognition (same fact, two views).

Inventory — SKU stock at warehouse/store. Attributes: SKU, location, qty, status (available/in-transit/locked). Links: belongs to SKU; located at warehouse/store; consumed by sales; generated by receipt/transfer notes. Actions: receipt, issue, allocation, replenishment, transfer. Business: allocation/replenishment/transfer ↔ Finance: stock account (same origin).

Budget Subject — Quota object at category × delivery period dimension (core gate carrier). Attributes: subject code, category, delivery period, total quota, deducted, available balance, status. Links: attached to category (× delivery period); constrains purchase orders; generates approval doc (when over). Actions: budget compilation, deduction, release. Business: order placement interception ↔ Finance: quota posting ( approval = immediate deduction , no month-end catch-up).

Approval Doc — Human decision carrier for over-quota/exceptions. Attributes: doc no, type, linked object (e.g., over-budget PO), applicant, status, red flag, approval result, receipt. Links: attached to reviewed object; generates action receipt. Actions: submit, approve, reject. Business: approval decision ↔ Finance: quota deduction & accounting treatment.

Metric — Semantic layer defined calculation instance (also linkable object). Attributes: metric code, name, caliber, owner, status (draft→confirmed→published). Links: defined in metric dictionary; sourced from dataset (single retrieval path); presented in scenes. Actions: define, change caliber, publish. Business: operating metrics ↔ Finance: financial metrics share same dictionary.

Scene — Page station registration object (scene is data not code). Attributes: scene code, name, group (prod/supply/sales/HR/finance/logistics), registration info, wired datasets. Links: wired to datasets (reverse push); via edge table to types; retrieves via registry. Actions: register, wire, flip (evidence chain). Business: front tells business ↔ Finance: back gives evidence.

Dataset — L2 versioned output (wired to objects at L3). Attributes: dataset ID, version, source, update time, birth certificate. Links: wired to scenes; supports metrics. Actions: ingest, process, version upgrade. Business & finance share same dataset (no copying).

Note: Above catalog derived from slide material (15+ scene stations: merchandise planning, metric center, procurement desk, sales analysis, accounts payable, P&L, supplier desk, allocation/replenishment workstation, warehouse desk, business-finance budget, etc.) with suggested field specs.

Link Type Table

Defines 12 link types with direction, semantics, suggested cardinality. Key principle: "BI's backbone is metrics, ontology's backbone is object relationships. Link modeling precedes metric modeling — links fixed, metrics naturally don't fight." Types include: generates, contains, belongs to, affiliated to, consumes, settles, validates, wires, retrieves from, defined in, approved on, triggers.

Action Specification (Action Schema)

Every action must include six schema elements, none missing for audit release:

Input — Action parameters and linked objects with schema definition. Example (PO submit): PO ID, SKU lines, amount, delivery period.

Pre-validation — Checks before execution, including gate validation. Example: category × delivery period quota check: order amount ≤ available balance? — if excess, immediate block, prompt confirmation to approval .

Approval — Approval flow wiring when threshold exceeded/validation fails. Example: over-budget → generate approval doc with auto red flag into approval flow.

Execute — Actual change logic after approval. Example: at approval moment quota posts (immediate deduction) , order status → placed.

Write-back — Result written back to ontology, updating object state. Example: budget subject "deducted" updated, available balance real-time updated; object state change triggers downstream updates (flywheel turns again).

Audit Trail — Receipt: who, when, based on what, changed what. Action receipt stored, forming minimum requirement for "every decision has a receipt".

Guardrail Requirements : Actions have schema, guardrails (pre-validation + approval + permissions), approvals; permissions and receipts live on foundation, not in prompts. AI (Agent) initiated actions and human initiated actions share same schema, same guardrails.

Semantic Layer Specs (L4)

Metric Dictionary Field Specs (Suggested)

Metric code/name — globally unique code; name uses unified semantics (one vocabulary).

Business definition — one-sentence business meaning.

Caliber (calculation logic) — numerator/denominator, time window, filters, source metrics and datasets (single retrieval path).

Dimensions — drillable dimensions (e.g., year/quarter/month, category, store).

Owner — caliber owner (queryable, accountable).

Status — state machine: draft → confirmed → published (see 5.2).

Version & change log — before/after definitions, change reason, approver, effective time — system queryable, not in chat logs.

Baseline rule — e.g., DuPont tree baseline = last year same window × growth rate (registered as example caliber).

Metric State Machine & Change Process (Caliber Changes Follow Process)

State machine: draft → confirmed → published.

Change process (any caliber modification must complete full flow):

Apply : Owner initiates caliber change in dictionary, fills new definition, reason, impact scope (system auto-lists referencing scenes/pages).

Review : Stakeholders confirm impact.

Publish : Upon approval, effective immediately, caliber changes once, whole platform follows ; before/after records archived queryable.

Constraint : Without touching registry, no one can change a number — pages and Agents forbidden to bypass dictionary and privately alter caliber.

Business Rule Library Specs

Rule four elements (suggested): rule code, rule content (condition → conclusion), owner, status.

Rule collection, status, owner all in library , not scattered in heads or chat logs.

Rules wired to action pre-validation (4.4): rule library is source for gate validation and approval red flags.

Metric dictionary + business rule library = dual registry (data governance core, see Part 05).

Data Integration Layer Specs (L2)

Access Contract

Each source system (MES/ERP/PLM/WMS/POS/SRM/OA/Finance) signs contract before integration: schema, field semantics, update frequency, timestamp caliber, owner. Access wizard (demo feature) guides contract registration.

Cleansing, Processing & Versioning

Multi-source heterogeneous ingestion → pipeline cleansing → output clean, trusted, traceable datasets.

Dataset versioning : each processing run generates new version, historical versions traceable (when decisions questioned, can restore numbers at that time).

Processing logic itself included in lineage (every hop in processing chain queryable).

Birth Certificate Requirements

Every table/number must register metadata (suggested fields): source system, ingestion time, processing chain (hop-by-hop pipes and steps), version (current + historical pointers), owner, health status (freshness, break status for breakage red alerts).

Column-Level Lineage & Break Detection

Column mapping : source column → processing column → metric → page field, hop-by-hop registration, end-to-end lineage (data map / hydrograph) queryable.

Breakage auto-alerts : data freshness monitoring, timeout = breakage, lineage DAG break point auto red-flagged, page numbers show red light (stale data auto-alerts).

Single retrieval path : metric → dataset retrieval relationship unique, no copying, no second truth.

Application Layer Implementation (L5)

Scene Stations (Four-Step Wiring)

New scene launch = four-step wiring, zero code (scene is data not code):

Register : vertical column registers one row, grouped by domain (prod/supply/sales/HR/finance/logistics).

Reverse Wire : dataset reverse-pushes to scene, no data moving, no copying .

Edge Table Wiring : scene-type edge written to graph, relations queryable and verifiable.

Registry-Driven Retrieval : page retrieves via registry, caliber same-origin with foundation.

Scene Flip-Side Evidence Chain (three tabs, fully auto-generated, zero hand-written):

Overview: front tells business.

Source & Processing: birth certificate + processing chain.

Key Provenance: caliber declaration ⊕ system-measured reconciliation card , exact match green light.

First batch scene stations (15+, grouped): merchandise planning, metric center, procurement desk, sales analysis, accounts payable, P&L, supplier desk, allocation/replenishment workstation, warehouse desk, business-finance budget, etc.

Budget Gate (Four-Step Flow)

Excess triggers confirmation : order hits quota, system blocks immediately.

Approval doc auto red-flag : over-budget request enters approval flow with red flag.

Approval = immediate deduction : at approval moment quota posts, no month-end catch-up.

Balance real-time visible : category remaining quota queryable anytime.

Gate dimensions: category × delivery period . Principle: intercept before commitment, not explain after month-end.

Sandbox Simulation

Counterfactual simulation : change store count, category structure, model recalculates on the spot (e.g., +30 stores → sales/cost/profit recalc).

In-season deviation monitoring : actual sales vs forecast (P50), deviation beyond threshold auto-triggers actions (insight-to-action loop: problem directly becomes proposal).

Alert ledger : alerts have ledger, same event not reported twice.

Closure : proposal → approval → execution → effect write-back, all in system.

Automated Reconciliation

Caliber consistency (L4) is prerequisite; reconciliation shifts from human work to system obligation.

Reconciliation card mechanism: caliber declaration ⊕ system measurement, exact match green light.

Living DuPont tree: year/quarter/month three-level drill, baseline = last year same window × growth rate, every leaf drillable to source doc.

Flywheel & Write-Back Mechanism

Flywheel four rings (benchmarking Palantir Foundry's flywheel):

Data Integration : multi-source ingestion · pipeline cleansing · dataset versioning → clean, trusted, traceable.

Ontology Modeling : objects · properties · links · actions → unique business semantics, humans and AI read same.

Applications & AIP : pages and Agents both built on ontology → humans view pages for judgment, AI finds data, reasons, proposes solutions.

Action Write-Back : validation · approval · execution, result written back to ontology → object state updates, full audit trail.

Write-Back Is Next Round's Input — Flywheel mechanism design:

Action executes → object state updates → triggers downstream updates : e.g., PO "placed" → budget subject immediate deduction update → available balance changes → affects next order's gate validation.

State changes propagate as events on link graph (4.3 "triggers" links), downstream objects/metrics/pages update via subscription.

Every flywheel turn leaves audit trail (receipt), receipts become fact input for next round's analysis.

Implementation constraint: all write-backs must go through action schema (4.4), direct bypass writes to object state prohibited.

Agent Foundation Specs (AI-Native)

Ontology is the foundation for all Agents. Four capability implementation requirements:

Continuity : context flows across Agents — previous session's notes usable by next; session context linked to objects/receipts (suggested: context attached to ontology objects), not scattered in chat logs.

Interoperability : Agents don't pass screenshots or Excel, pass the same objects ; inter-Agent data exchange uses ontology objects and links as carrier.

AI-Native : objects, relations, actions inherently machine-readable; actions have schema, guardrails, approvals.

Human + AI Collaboration : AI proposes, human approves, system executes, full audit trail — permissions and receipts live on foundation, not in prompts .

AIP Query Constraints : Assistant answers only from fact layer (L3 ontology + published metrics), no private calculations; answers include clickable referenced objects (lineage straight to source) — this constraint is the mandatory AI version of "one chain".

Golden Rule Constraint : "A single tree cannot make a forest" — personal efficiency gains ≠ enterprise efficiency reform. More Agents → greater need for one shared tree: any Agent must attach to ontology foundation to gain retrieval and action permissions.

Implementation Roadmap

Each phase states goal, deliverables, acceptance criteria. Phases may partially overlap but dependency order cannot be reversed.

Phase 1: Lay Foundation (L1–L3)

Goal : Integrate heterogeneous systems, establish integration and ontology foundation, stand up the "one number" tree trunk.

Deliverables : L1 system registration (MES/ERP/PLM/WMS/POS/SRM/OA/Finance); access contracts; pipeline cleansing & dataset versioning mechanism; birth certificate metadata; column-level lineage; core object modeling (Ch 4.2 catalog: product/SKU, category, store, supplier, PO, sales order, inventory, budget subject, etc.) and links; break detection.

Acceptance : Source doc → processing → object chain queryable no copying; every object has birth certificate; breakage auto red-flag; core objects wired to real data with business/finance same-origin verifiable.

Phase 2: Semantic Layer & Metric Dictionary (L4)

Goal : Caliber only here, "number fights" ended.

Deliverables : Metric dictionary (with state machine & change process); business rule library (dual registry); unified retrieval path (metric→dataset); first batch metrics published (actual sales, budget execution, P&L related, DuPont tree calibers & baseline rules).

Acceptance : 100% metrics from dictionary, pages zero private calibers; caliber changes follow process with before/after queryable; rules have owners, status, all in library.

Phase 3: Core Scene Stations & Budget Gates (L5 First Half)

Goal : Business uses it, budget becomes controllable.

Deliverables : First batch scene stations live (procurement desk, accounts payable, sales analysis, business-finance budget, warehouse/allocation workstation, etc., wired via four-step method); scene flip-side evidence chain three tabs with reconciliation cards; budget gate four-step flow (category × delivery period); automated reconciliation green light; living DuPont tree (year/quarter/month drill).

Acceptance : New scenes launch via four-step wiring (zero code); every page flip-side has evidence chain with reconciliation green light; order placement over-quota intercepted real-time, approval red-flagged, approval = immediate deduction, balance real-time; reconciliation exact match.

Phase 4: Sandbox & Agents (L5 Second Half + AI-Native)

Goal : Simulate before commit, insight-to-action closure, Agents on tree.

Deliverables : Counterfactual simulation (store count/category structure recalc); in-season deviation monitoring (actual vs P50, threshold triggers proposal, alert ledger); AIP query (fact-layer only, references clickable); action schema open to Agents (AI proposes, human approves, system executes); command center / data health ops apps.

Acceptance : Simulation results writable as proposals through approval & execution; deviation threshold auto-generates proposals, alerts deduplicated; Agent retrieval fact-layer only, actions full schema/guardrails/approval/receipt.

Governance & Metrics

Data Source Audit (Daily Auto Check-up)

System daily auto check-up: which systems data from, when arrived, broken or not, stale or not.

Health cockpit: four cards + trend curves.

Lineage DAG break points auto red-flagged.

Registry Governance

Dual registry (metric dictionary + business rule library) is governance core: metric definition, owner, status (draft→confirmed→published) all follow process; change definition, before/after system queryable.

Caliber changes once, whole platform follows; without touching registry, no one can change a number .

"One Number / One Chain / One Gate / One Sandbox" Acceptance Metrics Checklist

One Number : Sales/finance/supply chain same metric retrieval consistency 100%; page private caliber count = 0; reconciliation green light rate = 100% (steady state no red lights).

One Chain : Metric lineage coverage 100% (column-level); any page number ≤3 hops to source doc; break detection timeliness 100%; decision receipt retention 100%.

One Gate : Order budget validation interception 100% (excess must prompt confirmation); approval red-flag coverage 100%; approval-to-deduction latency = 0 (real-time posting); month-end catch-up over-quota items = 0.

One Sandbox : Counterfactual scenarios cover core decisions (store opening/category structure); in-season deviation alert auto-proposal rate 100%; same alert duplicate rate = 0 (alert ledger deduplication); proposal→approval→execution→effect write-back closure rate 100%.

Risks & Open Items

Following issues require business sign-off during implementation; document only lists and suggests:

Budget gate delivery period granularity : by wave, by month, or by season? Suggest align with merchandise planning launch waves (category × delivery period is gate dimension, granularity needs business confirmation).

Store object online/offline boundary : POS channel and e-commerce channel unified as one "store" object with type attribute, or separate modeling? Suggest unified object + type attribute, channel as dimension.

Metric dictionary first batch scope : DuPont tree metrics (ROE decomposed to sales/cost/profit) priority, but specific metric list needs joint finance/business review.

Approval flow integration with existing OA : Approval doc object relation to existing OA approval system (reuse OA flow or ontology self-built flow)? Suggest receipt must flow back to ontology for audit, flow engine can reuse OA.

Historical data lookback depth : Decision traceability (restore numbers three months later) depends on dataset versioning retention policy, need to define retention strategy.

P50 forecast ownership : In-season deviation monitoring needs forecast baseline (P50), who produces and maintains forecast model must be clarified.

Agent action permission boundaries : AI auto-executable action whitelist (query only? low-value proposals?) needs governance committee; default suggestion: AI always proposes, human approves, system executes.

Sandbox model caliber : Counterfactual recalculation model (e.g., +30 stores → sales/cost/profit) elasticity coefficient source (historical regression or business assumption) needs business confirmation.

This document is based on the Business-Finance Single Account — Single Source of Truth in the Digital World design share slides, serving as implementation blueprint and modeling standard. Document version rolls forward with implementation phases; caliber content authoritative only in registries (metric dictionary / business rule library).