# 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:
- email
- 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.