# Idiosyncrasy — Product Definition & Core Principles ## Provisional v0.2 — September 2026 ## 1. Product definition 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. It is intentionally holistic. It should progressively provide the capabilities a business needs rather than forcing the customer to assemble a large collection of disconnected SaaS products. The customer should not need to become a software developer, database designer or prompt engineer. The core proposition is: > **Software that learns your business, rather than making your business learn the software.** Idiosyncrasy should be capable of starting with a small business model and progressively expanding it as the business grows, changes and discovers new requirements. ## 2. The four primary product principles ### 2.1 Ease of use Business users describe needs in business language. They should not need to understand: - database architecture - APIs - application frameworks - workflow implementation - AI prompts - infrastructure - code Complexity belongs inside the platform. AI may help interpret intentions, but the resulting system must remain understandable, inspectable and editable. ### 2.2 Not AI-dependent; AI-supported AI is an optional intelligence layer, not the foundation of the business system. The deterministic platform must continue to operate if: - no AI provider is configured - an AI provider is unavailable - AI costs become undesirable - a model changes - the customer chooses not to use AI for a task AI can assist with: - configuration - content creation - analysis - recommendations - search - summarisation - marketing - workflow creation - optimisation - natural-language interaction - identifying patterns - proposing system changes The business model, data, workflows and core application behaviour must remain platform-owned and deterministic. ### 2.3 Self-optimising, suggesting and evolving Idiosyncrasy should observe how the business operates and identify opportunities to improve it. The default evolutionary loop is: > **Observe → Understand → Suggest → Approve → Implement → Measure** Suggestions may concern: - repetitive work - inefficient workflows - missing automation - duplicate processes - neglected customers - unusual performance - missing information - emerging business activities - opportunities to formalise knowledge - opportunities to introduce new structured properties - opportunities to create new workflows or views Idiosyncrasy should normally propose significant changes rather than silently making them. ### 2.4 Inherent growing knowledge Idiosyncrasy must develop persistent institutional memory for the business. This is broader than structured data and broader than AI memory. The platform must be able to retain: - business knowledge - policies - procedures - decisions - explanations - experience - notes - documents - contextual information - learned preferences - historical knowledge - relationships between knowledge and business objects Knowledge must have provenance and, where appropriate, status, ownership, applicability and dates. The longer a business uses Idiosyncrasy, the more accurately the platform should understand that business. ## 3. Structured retrieval principle Idiosyncrasy should retrieve business information by exploiting the structure of the Business Graph before relying on expensive semantic search. Because every addressable object has a `type`, object type is a guaranteed first-class retrieval dimension, but it is not the only one. Relationships, state, time, provenance, ownership, permissions and other deterministic characteristics should progressively constrain retrieval before semantic/vector techniques are used. This allows Idiosyncrasy to remain fast, predictable and scalable while still supporting natural-language and knowledge-rich queries. ## 3. Holistic platform principle Idiosyncrasy should aim to contain the major capabilities a business needs. Initial capability areas may include: - CRM - contacts and organisations - sales and pipeline - products and services - projects - tasks - operations - marketing - email marketing - social media campaigns - website/CMS - forms - customer communications - documents - reporting and analytics - automation - knowledge management - customer portals - finance-related workflows - integrations - AI-assisted operations This is not a fixed module list. The platform must be extensible. A capability is preferably assembled from common engines and primitives rather than becoming a completely isolated application. ## 4. Universal data primitive Idiosyncrasy uses one foundational data model throughout the platform. All persistent and addressable platform data is represented using the same primitive: ```text Object = { id, type, value } ``` This is an architectural rule, not merely a convenient storage format. Business objects, configuration, knowledge, workflows, events, rules, policies, goals, decisions, relationships, UI definitions, integration records and other addressable data must adhere to the same `id + type + value` model. The platform must not introduce separate bespoke object schemas for individual modules or conceptual layers merely because the data has a different business meaning. Meaning is provided by `type`, the structure of `value`, relationships, type definitions, behaviour and context. This creates a continuously extensible model: new business concepts can be introduced as new types without changing the fundamental data architecture. New capabilities should therefore extend the platform's vocabulary and behaviour rather than create parallel data universes. The primitive does not mean that all values are unstructured. Type definitions may describe valid value structure, validation, relationships, permissions, lifecycle and behaviour. The important distinction is that these definitions are themselves addressable data using the same primitive. ### Architectural rule > **There is one fundamental object model in Idiosyncrasy. All platform data uses `id + type + value`. No module may introduce a competing foundational data structure without an explicit architectural decision.** ## 5. The platform versus modules The platform should distinguish between: ### Core primitives Reusable concepts such as: - the universal `id + type + value` object primitive - type definitions - properties/values - relationships - records - events - states - permissions - files - knowledge - workflows - actions - views - forms - notifications - integrations ### Engines Reusable execution/configuration systems such as: - Object/Data Engine - Relationship Engine - Workflow Engine - Knowledge Engine - Content Engine - UI/View Engine - Automation Engine - Communications Engine - Analytics Engine - Integration Engine - Permission/Identity Engine - AI/Intelligence Layer ### Capabilities Business-facing systems assembled from the engines: - CRM - Marketing - CMS - Sales - Projects - Operations - etc. ### Applications The actual interfaces and experiences presented to a particular business. This hierarchy prevents the architecture becoming a collection of unrelated modules. ## 6. Extensibility and new capabilities Idiosyncrasy must not assume that every future business requirement is known in advance. When a new requirement appears: ### Level 1 — Existing capability Use existing functionality. ### Level 2 — New configuration Construct the capability from existing primitives and engines. ### Level 3 — New engine If the requirement genuinely cannot be represented by the existing architecture, introduce a new reusable engine. A new engine should become a platform capability rather than a one-off customer hack wherever possible. The platform should therefore be capable of evolving its own capability set over time. AI may assist humans in designing new configurations and engine definitions, but foundational engine changes should be governed and testable. ## 7. Business ownership The customer's business model is a first-class asset. Idiosyncrasy should make the business representation: - readable - editable - exportable - versionable - inspectable - independent of a particular AI model AI-generated configuration must not become an opaque black box. ## 8. Competitive philosophy Idiosyncrasy should not compete primarily on: > "We have AI that can build an app." AI coding tools increasingly make application construction accessible. The stronger proposition is: > **Idiosyncrasy provides the persistent business model, application runtime, workflow system, knowledge layer, integrations and evolutionary mechanism that allow a business to have software which continuously adapts to it.** The customer is buying an operating platform, not a code generator. ## 9. Long-term product ambition The intended trajectory is: > Business description → Business model → Applications → Operations → Knowledge → Observation → Suggestions → Evolution The platform should progressively become the digital operating representation of the business without requiring the business to maintain a software department.