Product Definition
Status: settled product/architecture direction, 2026-09-11. Initial implementation mechanisms are specified separately; this document is not a claim of built functionality.
Owns: product purpose, principles, business ownership promise, composition terminology, extensibility levels and the architectural test. The core object model and authority provides the cross-cutting conceptual foundation; technical contracts belong to their architecture owners; release scope belongs to the roadmap.
Lineage: source 01, with the corresponding product sections of source 00; composition also incorporates source 02 sections 12, 13 and 17 and source 03 section 8. See the source ledger for section-level preservation and archive lineage.
Purpose and Audience
Idiosyncrasy is a business-adaptive application platform: software that models how a business actually works and provides the applications, workflows, knowledge, automation and interfaces required to operate it.
> Software that learns your business, rather than making your business learn the software.
The intended customer wants to run and improve a business, not become a software developer, database designer or prompt engineer. A small initial business model should grow as the business changes and discovers new needs.
The product is intentionally holistic. CRM, operations, websites, knowledge and other business capabilities should work against a shared representation instead of obliging the customer to assemble disconnected SaaS products and repeatedly reconcile their information.
"Anti-SaaS SaaS" describes this rejection of rigid, fragmented application boundaries, not a decision about hosting, subscriptions or pricing. Holistic ambition is not a promise to finish every capability in the MVP.
Idiosyncrasy is deterministic first: it models, operates and continuously evolves a business through shared objects, relationships, state, history, knowledge, workflows, logic, authority, provenance, external interactions, datasets, communication and analytics. Optional AI assists that platform but is never its foundational authority. The platform should hide implementation complexity without hiding business capability or human control.
The platform stores facts, evidence, relationships and history, then derives conclusions and conditions from them. It must not create duplicated classifications for combinations such as Business existence, recognition, representation, authority, subscription or remaining capacity when those conclusions can be derived from the authoritative model. Materialized projections may support performance and presentation, but they remain subordinate to the underlying objects, relationships, entitlements, authority and history.
The primary experience is the business as a coherent whole. A person should first see what exists, what is happening, what changed, what needs attention, what the system has done, what it suggests and what they can decide. Mechanical detail remains available for understanding, investigation, configuration, authorisation and audit, but it should appear progressively in response to the user's depth of intent.
The product hides mechanical complexity without hiding business meaning. It should present business concepts and the holistic containing object before raw identifiers, relationship mechanics or internal graph structure, while retaining deliberate access to constituents and technical detail for authorised investigation. An object being empty or partially configured does not justify hiding it when its existence is meaningful; the product should show what is known, what is unresolved and what can be done next.
Business, Identity, Authority and Subscription
A Business is an independent first-class Idiosyncrasy entity. Its identity, data, Business Graph, Business DNA, models, workflows, knowledge, configuration, history and governance do not structurally belong to an Account, User, subscription, tenant, agency or customer record.
A User is an authenticated account that signs into Idiosyncrasy and is the platform identity and authority subject. (The earlier term "Principal" is superseded; see identity and governance.) A Person is an individual profile defined within one Business; a User may be associated with a Person in a Business, and neither requires the other. An authorised User may create a Business through the governed mutation path. Creation records creator provenance and assigns initial administrative authority; it does not establish permanent ownership. Authority is independently governed and may be delegated, restricted, transferred or revoked, so a different User may later administer the same Business without changing its identity.
A subscription is a commercial and operational entitlement, not ownership, authority, creator identity or administrator identity. The payer or subscription manager need not be the creator or sole administrator. These concepts are defined by identity and governance, Business model, and subscriptions and entitlements.
Commercial model (intended future architecture; not implemented). Idiosyncrasy sells Business subscriptions only. User registration and Business creation are free, a Business may exist indefinitely without a subscription, and Guest Users are free and never counted. Licensed Users count towards the Business subscription band; Licensed status never grants authority, which remains with Membership, AuthorityGrant and Policy. The model, working billing bands and unresolved pricing-transition rules are owned by subscriptions and entitlements. Currently all Businesses are treated as active and no subscription enforcement exists; nothing in this model restricts the current build or the first executable milestone.
Capability definitions and capability objects may exist independently of subscription. Subscription and authority can constrain what information, depth or operation is available without removing the underlying Business representation or capability composition. The product should present useful permitted Business value and preserve human understanding while progressive disclosure hides mechanical detail; it must not turn access control into a conventional feature-paywall model.
Single-business, multi-business, agency and multi-tenant descriptions are commercial or isolation arrangements, not competing Business identity architectures. The platform must not assume fixed Account-to-Business ownership or equate Business with tenant. An authorised identity may administer zero, one or many Businesses according to governed authority and applicable entitlement.
An inactive Business subscription (intended future architecture; all Businesses are currently treated as active and nothing is enforced) preserves the Business and its governance but suspends Business-scoped operational execution. The canonical invariant and retained-state semantics belong to subscriptions and entitlements; operational responsibilities must consume that invariant rather than define competing suspension rules.
Product Principles
Ease of Use
Business users describe requirements in business language. They should not need to understand database architecture, APIs, frameworks, workflow implementation, AI prompts, infrastructure or code to operate their business.
Complexity belongs inside the platform. Configuration, decisions and resulting behavior must nevertheless remain understandable, inspectable and editable. Hiding implementation complexity must not hide business meaning or remove human control.
Human-operated forms, views and configuration are essential, not a fallback available only when a conversational interface fails. AI may interpret intent, but a useful system must not depend on users finding the right prompt.
Business configuration is progressive rather than a requirement for a fully configured Business at creation. Manual entry, relationships, workflow activity, imported or observed information, Definition adoption and later human decisions may each add understanding. The product may surface derived attention and epistemic distinctions, but neither attention nor confidence becomes a second authoritative state or authority model.
AI-Supported, Not AI-Dependent
The deterministic business platform must continue to operate when no AI provider is configured, a provider is unavailable, costs become undesirable, a model changes, or the customer declines AI for a particular task.
Optional assistance can cover configuration, content creation, analysis, recommendations, search, summarisation, marketing, workflow creation, optimisation, natural-language interaction, pattern identification and proposed system changes.
The business model, data, workflows and core application behavior belong to the platform runtime, independently of a particular model. AI outputs are proposals or inputs subject to deterministic validation and authorization before execution, not an alternate authority channel.
The AI contract owns intelligence boundaries; identity and governance owns permissions and approvals. Every scoped business capability must retain a no-AI operating path.
Suggestion-Led Evolution
The intended improvement cycle is Observe -> Understand -> Suggest -> Approve -> Implement -> Measure. Its operational contract belongs to analytics and evolution.
Candidate improvements include repetitive work, inefficient workflows, missing automation, duplicate processes, neglected customers, unusual performance, missing information and emerging business activities. They also include opportunities to formalise knowledge or introduce structured properties, workflows and views.
For example, noticing that people repeatedly create the same three tasks after a sale should lead to a reviewable post-sale workflow suggestion, followed by approval and measurement. It must not silently install a new business process.
Significant changes should normally be proposed to the business. Definition improvement and configuration adoption are separate from suggestion: an existing instance does not change definition until an appropriately authorized decision creates the new revision. The precise autonomy configuration and risk thresholds remain human decisions; "self-optimising" does not grant unbounded self-modification.
Attention and Epistemic Clarity
Attention is a primary product concern. The platform should surface consequential changes, pending decisions, failures, useful recommendations, opportunities and other meaningful changes without turning routine successful automation into noise. Attention is contextual to the object being viewed, the relevant Business, current state/activity/consequences, the logged-in user and that user's authority and permissions. Watching may be implicit through sensible context and defaults as well as explicitly controlled for objects, collections, business areas, processes and metrics. A user may see permitted information about an action without being authorised to initiate or approve it; an unauthorised action must not be presented as available to that user.
The interface must preserve the difference between an authoritative fact, a deterministic calculation, an inference, a suggestion and an unknown. A plausible value is not authoritative merely because it is available. Primary views should communicate the relevant basis, source, provenance or qualification concisely, with deeper explanation available when needed.
Capabilities are business/product compositions rather than a fourth semantic object role or permanent module boundary. Marketing, finance, personnel, logistics and other domains may be composed from the shared Object model, Definitions, Relationships, Operations and Presentation Objects; the capability catalogue is not a fixed taxonomy or a promise that every domain is an independent application. Data, Workflow, Logic and Presentation are semantic roles within the universal Object model. A Definition describes an Object composition and its relevant constituent structure; Business configuration is expressed by ordinary Objects, Relationships and Configuration, not a special primitive, adoption subsystem or assignment mechanism. “Capability” is product language, not an architectural type.
Inherent Growing Knowledge
The platform must retain institutional memory broader than structured properties or AI conversation history: policies, procedures, decisions, explanations, experience, notes, documents, context, learned preferences and historical knowledge.
Knowledge should connect to the business objects it concerns and retain provenance and, where appropriate, ownership, status, applicability and dates. The longer the business uses the platform, the richer its useful business context should become.
For example, a contact preference can be structured while the explanation for that preference remains knowledge. Repeated observations may justify a suggestion to introduce new structure; they are not automatically authoritative facts.
Knowledge owns these distinctions. Retrieval owns structured-first access using types, relationships, state, time, provenance, ownership and permissions before optional semantic search. Neither responsibility is AI-only.
Composition and Extensibility
This section is the canonical home of the composition taxonomy and the test for extending it. The architecture overview maps responsibilities to owners; it does not independently define them.
| Term | Meaning and boundary | |---|---| | Primitive and Type | The foundational object model and addressable semantic definitions are specified by objects and types. Properties, files, events, permissions, knowledge and workflows do not establish competing foundations. | | Engine | A reusable execution responsibility or capability of the platform. It is not inherently a PHP class, module, database subsystem or separately deployed service. | | Capability | A business/product composition, such as Marketing, Accounts, CRM, Sales or Operations, assembled from shared Objects, Definitions, Relationships, Operations and Presentation Objects. It is not a semantic role, special Type, separate data model, engine, store, runtime, module or application boundary. | | Definition used for a product composition | An ordinary platform-provided, revisioned reusable Definition containing the complete recursive Object composition required to describe the relevant semantics and behaviour. It is not a Type list, traditional SaaS module, subsystem, engine, datastore or application boundary. | | Business configuration of a product composition | Ordinary Business-scoped Objects, Relationships, Configuration, exact Definition/revision references, Presentation Objects, Authority and retained provenance. This replaces the architectural notion of a Business Capability Instance without creating a replacement special type. | | Application | The actual interface and experience presented to a particular business, projecting the shared model through its capabilities. Rendering and configuration contracts belong to views and content. |
A Definition used for a product composition may contain ordinary Objects that themselves contain or reference further Data, Workflow, Logic, Relationship, Presentation or Configuration Objects. These are semantic descriptions within one universal Object system, not separate object classes or stores. The current generic model is:
Definition
-> governed Business configuration binding exact Definition identity/revision
-> ordinary Business Objects and Relationships
-> Presentation Objects and Authority projection
Applying or configuring the Definition establishes Business-owned Objects and Relationships through the existing generic containment, reference, revision, provenance and governed mutation mechanisms. The Definition remains unchanged. Definition identity/revision is distinct from release/publication identity and provenance, which remain retained evidence rather than substitutes for semantic Object identity.
Applying or configuring a Definition for a Business creates or resolves ordinary Business Objects and Relationships whose current constituents, workflows, Operations, presentation choices, release/version binding and provenance express that configuration. Constituents can subsequently be established, replaced, modified or removed through normal Data, Workflow and Logic execution where governed. This is the universal Object mechanism; it does not create a new semantic role, capability store, adoption subsystem or special assignment path, and it does not mutate the standard Definition.
There is no capability Derivation layer in the current product. The future derivative path is distinct: a standard platform Definition is instantiated for a Business; the instance is modified through normal Data, Workflow and Logic mechanisms; a recurring configuration may become a candidate reusable derivative or pattern; and promotion into a platform-level Definition or pattern requires explicit human authority. Platform Definitions must not mutate automatically from observed Business behavior, and no current capability Type, engine, workflow or persistence model represents this future path.
The fourteen responsibilities in the architecture map preserve distinct architectural concerns, not a mandate for fourteen modules, classes or services. One implementation unit may realize several responsibilities; a responsibility may need several implementation components.
Modules and adapters are implementation packaging or integration boundaries, not owners of separate business-data universes. A new business noun, screen or customer request is not evidence that a new engine is needed. An Operation may belong to or support a Capability, while its exact contract and execution boundary remain owned by Operation Contract; neither is synonymous with the broader Capability Definition.
Non-Overridable Foundations
Idiosyncrasy is a semantic runtime that interprets extensible business definitions. A Business can define concepts the original developers never anticipated, using Types, Relationships, addressable States, Workflows, Policies and Views within the universal model. A Client, Project, Enquiry, Proposal or newly invented business concept extends that vocabulary; it does not create another modelling system.
Business definitions and configuration cannot redefine or disable foundational authentication, authority, provenance, state-transition, Policy-enforcement or commit-integrity semantics. These runtime obligations remain in force for every extension, including definitions authored by humans or AI. Approval of a configuration change does not grant permission to bypass them.
Defining a domain lifecycle or an explicit governed Policy exception is permitted configuration; declaring that transitions need no authoritative validation/history, that a relationship supplies unrestricted authority, or that a successful UI response replaces durable commit is not. Businesses configure meaning and permitted behavior within the foundations, not the enforcement semantics of the foundations themselves. New reusable engine behavior must conform to the same boundary; implementation simplicity cannot remove it.
Three Extensibility Levels
| Level | First response to a requirement | |---|---| | 1. Existing capability | Use functionality already available and configure its ordinary options. | | 2. New configuration | Assemble the requirement using existing types or new type definitions, relationships, knowledge, workflows and views supported by existing engines. | | 3. New engine | Introduce genuinely new reusable execution behavior only when the existing architecture cannot reasonably provide it through configuration. |
These are approaches to composition, not autonomy levels or deployment tiers. Prefer the lowest sufficient level without forcing a materially different behavior into misleading configuration.
A new engine should provide materially distinct, reusable execution logic that configuration alone cannot supply and that can benefit multiple capabilities. It should become a platform asset, not a one-off customer implementation.
Engine changes require versioning, testing, permission awareness, observability, documentation and assessment of their effect on business models. AI may help design configurations or engine definitions, but production changes require controlled human governance and validation.
Seven-Question Architectural Test
For every proposed feature, ask:
1. Can the data be represented using the existing id + type + value primitive? 2. Can an existing type definition express the required structure and validation? 3. Can existing relationships represent the required connections? 4. Can an existing engine support the behavior? 5. Is it simply new configuration or a new type? 6. Does it belong in a reusable capability? 7. Does it genuinely require a new engine?
Record the reasoning, especially the missing reusable behavior if a new engine is proposed. The equipment-servicing example demonstrates composition without an EquipmentServicingEngine.
Business Ownership
The customer's business model is a first-class asset. Its representation must be readable, editable, exportable, versionable, inspectable and independent of a particular AI model.
AI-generated configuration must not become an opaque black box. A business should be able to inspect what was proposed, what was approved, which configuration operates and how it has changed.
Exportability concerns meaningful business representation and its relationships, knowledge and configuration, not just isolated lists of contact fields. Explicit ownership, scope and version references are preserved by the model contract; concrete manifest packaging is an implementation mechanism, not a second model or a completed legal ownership agreement.
Business Graph and Business DNA owns representation and assembly. Identity and governance owns who may view, change, approve, share or export it.
Competitive Position and Long-Term Ambition
The primary proposition is not "AI that can build an app." AI coding tools make application construction increasingly accessible; generated code alone does not provide durable business context or an operating system for the business.
Idiosyncrasy provides the persistent business model, application runtime, workflows, knowledge, integrations and governed evolutionary mechanism through which software continuously adapts to its business. The customer is buying an operating platform, not a code generator.
The intended trajectory is Business description -> Business model -> Applications -> Operations -> Knowledge -> Observation -> Suggestions -> Evolution. The platform should become a digital operating representation of the business without requiring a software department.
An existing marketing application may supply reusable implementation or UI material. It imposes no data migration, compatibility, functionality-preservation or old customer-hierarchy obligation on this direction.
Boundaries and Implementation
This document does not define physical storage, identity encoding or a CMS provider. The initial runtime is a modular monolith, distribution-ready by contract; implementation architecture records chosen mechanisms. Implementation status must supply evidence before anything is described as built.
D01-D10 are settled. The Spearmint Design demonstrator follows the first governed executable milestone; neither a generic CRM nor the whole capability catalogue is required first. Missing code or concrete configuration is implementation work, not missing architecture approval.
Product conformance requires useful operation without AI, reuse across business capabilities, human-inspectable configuration, traceable changes and a credible path to export. Acceptance depth and demonstrators are defined in the roadmap, not inferred from the breadth of this ambition.