← Back to directory

01-idiosyncrasy-product-and-principles.md

archive/architecture-sources/01-idiosyncrasy-product-and-principles.md · 9.1 KB · 2026-11-02 12:48

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:

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:

AI can assist with:

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:

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:

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:

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:

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:

Engines

Reusable execution/configuration systems such as:

Capabilities

Business-facing systems assembled from the engines:

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:

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.