Architecture Map

Status: current navigation map, 2026-09-11. This document summarizes and links; it owns no detailed architectural definition. Every detailed meaning belongs to the canonical document named below.

Orientation

The product definition establishes Idiosyncrasy's business-adaptive purpose, four principles and ownership promise. Its composition and extensibility section defines Engine as a reusable execution responsibility/capability, not a class, module, database subsystem or service. It also owns the capability/application taxonomy and seven-question architectural test.

The core object model and authority defines the cross-cutting distinctions between actual object reality, definitions, derived State, history, workflows and explicit authority. The object/type contract defines the one foundational addressable model. The business-model contract defines its connected Graph, relationships and Business DNA. No engine below owns a separate data universe. This is a summary of those contracts, not an alternative storage model.

Conceptual Layer Routes

The eight layers from the architecture sources are views of concerns, not deployment tiers. Their details are authoritative only at the linked destinations.

| Source layer | Definition route | |---|---| | Cross-cutting object model and authority | Core object model and authority | | A. Identity and tenancy | Identity and governance | | B. Business model | Objects and types, Business DNA and relationships, semantics | | C. Business data | Universal objects, shared business representation | | D. Knowledge | Knowledge, with platform-wide retrieval | | E. Events and workflows | Time/events, workflow and scheduling | | F. Presentation | Views and content | | G. Integrations | Communication and integrations | | H. Intelligence | AI, with analytics and evolution |

Responsibility Map

Fourteen responsibilities are preserved. Their implementations may be combined or separated as justified; the canonical engine definition prohibits inferring fourteen rigid software units from this list.

| Responsibility | Canonical contract | |---|---| | Identity/Permission | Identity and governance | | Object/Data | Objects and types | | Relationship | Business model | | Event | Time and events | | Workflow | Workflows and automation | | Knowledge | Knowledge | | Content | Views and content | | View/UI | Views and content | | Communication | Communication and integrations | | Integration | Communication and integrations | | Analytics | Analytics and evolution | | Automation/Scheduling | Workflows and automation | | AI/Intelligence | AI | | Evolution/Optimisation | Analytics and evolution |

Structured retrieval is a platform-wide contract in retrieval, not an AI-only feature or a mandatory fifteenth module. Rules, policies, constraints, goals and decisions are defined in semantics, not competing execution/storage foundations.

Composition and Next Reads

The equipment-servicing scenario demonstrates composition from Objects + Types + Relationships + Knowledge + Workflow + Communication + Views, without requiring an EquipmentServicingEngine. The enquiry scenario demonstrates shared objects across forms, CRM, sales, tasks, communication and analytics.

Consult the roadmap for the first executable milestone and Spearmint Design process, implementation architecture for the chosen modular-monolith mechanisms, and status for evidence. D01-D10 are settled; implementation details are not new architecture decisions. Original and final-decision material is traced in the source ledger.