Idiosyncrasy — Initial Engines, Workflows & MVP
Provisional v0.2 — September 2026
1. Development strategy
Build Idiosyncrasy from the bottom up.
Do not start by building a large collection of disconnected business modules.
First create the reusable platform engines. Then use them to build the first visible business capabilities.
The MVP should prove the platform's central thesis:
> A business can be modelled once, and multiple useful applications and workflows can operate against that model.
2. Foundational data rule
Before the engines below are implemented, the MVP must establish the universal id + type + value primitive. This primitive applies to all persistent and addressable data in the platform.
The MVP must not create separate data models for CRM records, knowledge items, workflows, events, configuration, business-model definitions, UI definitions, relationships or other capability-specific concepts. All such concepts are represented as typed addressable objects using the same primitive.
Type definitions provide structure and validation; relationships provide graph connectivity; engines provide reusable behaviour. This separation is fundamental to Idiosyncrasy's continuous extensibility.
A new business concept should normally require a new type/configuration, not a database schema change. A new engine is justified only when genuinely new reusable execution behaviour is required.
2.1 Retrieval architecture requirement
The MVP must establish structured retrieval as a platform capability, not as an AI-only search feature. The type property of every universal object is a first-class indexing and retrieval dimension. Retrieval must use object type to narrow candidate sets before expensive semantic/vector retrieval.
The retrieval system should also exploit relationships, state, time, provenance, ownership, permissions and other deterministic characteristics where available. Semantic retrieval should operate over the already-constrained candidate set whenever possible.
This prevents the platform from treating the Business Graph as an undifferentiated corpus and provides a scalable path as the number and variety of object types grows.
3. Initial engine priority
Phase 1 — Foundation
Identity/Permission Engine
Required for:
- users
- organisations
- roles
- access control
Object/Data Engine
Required for:
- defining object types
- defining properties
- storing records
- CRUD operations
- validation
Relationship Engine
Required for:
- linking objects
- navigation
- contextual data
- cross-module operation
Event Engine
Required for:
- detecting business changes
- triggering workflows
- decoupling systems
Workflow Engine
Required for:
- business processes
- automation
- state transitions
- approvals
- scheduled actions
Phase 2 — Knowledge and interface
Knowledge Engine
Required for:
- documents
- notes
- policies
- procedures
- general information
- business memory
- contextual knowledge
View/UI Engine
Required for:
- forms
- tables
- detail views
- dashboards
- navigation
- generated interfaces
Content Engine
Required for:
- website content
- marketing content
- reusable content
- pages
- media
Phase 3 — Business operation
Communication Engine
Required for:
- notifications
- messaging
- templates
- communication history
Integration Engine
Required for:
- external services
- APIs
- webhooks
- synchronisation
Analytics Engine
Required for:
- reporting
- metrics
- dashboards
- workflow measurement
Phase 4 — Intelligence
AI/Intelligence Layer
Required for:
- natural language interaction
- content generation
- analysis
- recommendations
- configuration assistance
- knowledge retrieval
- workflow assistance
Evolution/Optimisation Layer
Initially lightweight; progressively expanded.
4. Initial business capabilities
The MVP should not attempt to finish every module.
It should prove a representative cross-section.
Recommended first capabilities:
Business Core
- Organisation
- People
- Customers
- Products/services
- Activities
- Documents
CRM
- contacts
- organisations
- opportunities
- interactions
- customer history
Workflow
- triggers
- actions
- conditions
- approvals
- scheduled tasks
Knowledge
- business knowledge base
- documents
- notes
- policies
- customer-specific knowledge
- search/retrieval
CMS
- pages
- content
- media
- reusable sections
- forms
Marketing
- campaigns
- audiences
- content
- scheduled communications
These capabilities must share the same underlying id + type + value objects and engines. No capability may create a parallel foundational data model.
5. Example cross-system workflow
A useful MVP demonstration:
> Website enquiry submitted
1. Form creates Enquiry object. 2. Enquiry relates to Person/Organisation. 3. Event enquiry.received is emitted. 4. Workflow evaluates enquiry. 5. Customer record is created or matched. 6. Sales opportunity is created. 7. Task is assigned. 8. Confirmation email is sent. 9. Interaction is recorded. 10. Knowledge can be attached if useful. 11. Dashboard metrics update. 12. AI may optionally summarise or classify the enquiry.
This single workflow demonstrates the value of a shared platform.
6. Knowledge workflow
Example:
> User uploads a PDF containing the company's pricing policy.
1. Document object is created. 2. Knowledge Engine extracts/indexes content. 3. Knowledge item is associated with the pricing policy. 4. Source and provenance are recorded. 5. AI can answer questions using the authorised knowledge. 6. Workflow rules can reference the policy where appropriate. 7. When the policy changes, the old knowledge remains historically identifiable.
7. Self-optimisation workflow
Example:
1. System observes repeated manual actions. 2. Evolution layer detects a pattern. 3. Pattern is assessed against permissions and thresholds. 4. Idiosyncrasy proposes an optimisation. 5. User reviews the proposed change. 6. User approves or rejects it. 7. If approved, configuration is updated. 8. System measures the result. 9. Outcome becomes part of the business knowledge/history.
8. Future capability creation
Suppose a customer requests equipment servicing.
First ask:
> Can this be represented using existing Objects + Relationships + Workflows + Views?
If yes, create:
- Equipment
- Service Contract
- Service Event
- Technician
- Parts
plus workflows and views.
No new engine is necessary.
If a large number of businesses later require specialist service scheduling, route optimisation and technician dispatch, a reusable Service Management capability may be introduced.
Only if the underlying behaviour cannot reasonably be supported by existing engines should a new engine be considered.
9. Human-operated first
Every major capability should be capable of operating without AI before AI is deeply integrated into it.
For example:
Marketing
First build:
- campaign object
- audience
- content
- scheduling
- approvals
- delivery
- tracking
Then add AI:
- campaign generation
- content generation
- audience suggestions
- performance analysis
- optimisation suggestions
CMS
First build:
- pages
- templates
- blocks/components
- media
- publishing
Then add AI:
- page generation
- copy generation
- SEO suggestions
- content restructuring
Workflows
First build:
- triggers
- conditions
- actions
- state
- execution
Then add AI:
- natural-language workflow creation
- workflow explanation
- optimisation suggestions
This keeps the platform useful and reliable independently of AI.
10. MVP success criteria
The MVP is successful if it demonstrates that:
1. A business can be represented without bespoke application code. 2. All persistent/addressable platform data uses the same id + type + value primitive. 3. Objects and relationships are reusable across capabilities. 4. Workflows execute deterministically. 5. Knowledge can exist outside structured data. 6. Knowledge can be related to business objects. 7. Interfaces can be generated/configured from the business model. 8. A new capability can be assembled from existing engines. 9. AI can assist without being required. 10. The system can suggest improvements. 11. Configuration remains readable and editable by humans and AI.
11. What not to build initially
Avoid:
- a huge number of shallow modules
- autonomous AI agents everywhere
- provider-specific AI architecture
- arbitrary runtime code generation
- complex microservice architecture without need
- bespoke customer-specific implementations
- trying to solve every accounting/ERP requirement immediately
- building integrations before the internal model is stable
The first objective is to prove the platform architecture.
12. Long-term expansion model
The product should grow in this direction:
Foundation → Business Model → Knowledge → Workflows → Interfaces → Core business capabilities → Integrations → AI assistance → Optimisation → New capabilities → New reusable engines where genuinely necessary
The platform becomes more capable for every customer without becoming architecturally dependent on any individual customer.