Architecture¶

OpsFactor separates data governance, planning models, long-running execution, and decision experiences. The separation keeps a workflow traceable from source records to a versioned plan and its physical and economic interpretation.

Responsibility map¶

From request to decision¶

1. A user or integration selects a planning object, scope, horizon, and configuration.
2. The application validates required references and creates or reuses the versioned plan header.
3. Factories load the required records in batches and index them into a consistent planning snapshot.
4. The selected engine executes without querying one entity at a time.
5. Results are materialized into named plan families such as Demand Plan, Supply Plan, production, distribution, inventory, or economic facts.
6. A Planning Book or analytical view reads those persisted results.
7. Approved modifications use the official service path so dependent quantities can be recalculated.
8. The release or Working Plan becomes the input for the next process.

The snapshot boundary matters: a calculation must not silently mix data loaded at different moments or in incompatible units.

Planning engines and plan semantics¶

Engines have different mathematical meanings and should not be described as interchangeable:

• statistical Demand Planning estimates future demand from history and configured signals;
• heuristic MPS/MRP processes network dependencies and capacities according to explicit priorities;
• Enterprise optimization compares alternatives simultaneously under constraints and an objective;
• Inventory Optimization uses stochastic simulation and sensitivity curves;
• Line Sequencing solves detailed temporal and combinatorial assignments;
• Finance interprets persisted physical facts and propagates economic effects.

For Supply Planning, public series use the stable labels Unconstrained Plan, Constrained Plan, and Working Plan. A heuristic constrained plan is a feasible rule-based result, not a claim of global optimality.

Long-running execution¶

Calculations that can exceed an interactive request run as observable tasks. A task should expose at least the requested operation, plan reference, status, timestamps, progress when available, and an actionable failure.

The application service owns transaction boundaries around plan creation, cleanup, and materialization. A failed new execution must not appear as a completed plan. When diagnostic artifacts are intentionally preserved, the state must remain explicit.

Performance and consistency principles¶

• load relationships in batches and avoid query-per-row behavior;
• reuse indexed projections for calculation and analysis;
• persist large output families in batches;
• keep units and calendar conversions explicit;
• fail on missing mandatory economic or conversion data instead of substituting a plausible zero;
• preserve immutable baselines and apply user changes to the intended working version;
• regenerate dependent analytical outputs after material changes to the physical plan.

Community and Enterprise boundary¶

The Community foundation owns reusable domain contracts, the public execution paths, and explicit extension points. Enterprise capabilities consume or extend that foundation. The Community runtime must not depend on private entities, tables, or implementations.

An edition label in a UI is not proof that a capability executes. Runtime catalogs and the corresponding versioned release define what can actually be selected. The functional pages contain a comparison table for each domain; the Community overview identifies the public baseline.

Examples of the current architectural split include:

• Community statistical Demand Planning; Enterprise advanced statistical and AI models;
• Community heuristic MPS/MRP; Enterprise global optimizer and process orchestration;
• Community aggregate production Planning Book; Enterprise detailed Line Scheduling;
• Community single-flow operational Deployment; Enterprise multi-item analytics and load formation;
• Enterprise Network Design, Inventory Optimization, and detailed Cost-to-Serve.

Security and tenancy¶

Authentication, authorization, tenant isolation, audit, secret handling, and environment topology are deployment contracts. They must be published with the distribution that implements them. Functional documentation never implies that a source checkout alone provides an Enterprise operating model.

Extension rules¶

A valid extension declares:

• the shared contract it implements;
• required data and validation;
• whether it adds a new planning engine, output, view, or integration;
• transaction and cleanup behavior;
• edition and runtime availability;
• regression evidence and documentation for the version that ships it.

Private extensions may reference shared objects. Shared code must never reference a private type.

Continue with Data integration, the functional journeys, or Community architecture.