← Back to directory

roadmap.md

product/roadmap.md · 27.4 KB · 2026-11-02 12:48

Roadmap and MVP Scope

Status: settled demonstrator direction, 2026-09-11. Implementation order and acceptance are specified below; no milestone is claimed as built.

Owns: MVP boundaries, phase priority, human-operated-first sequencing, success criteria, demonstrations and exclusions. Engine contracts belong to their canonical architecture owners; the product definition owns product intent and composition rules.

Lineage: source 03 in full for MVP intent, priorities, examples, success criteria and exclusions; corresponding source 00 sections and the principles in sources 01 and 02. See the source ledger.

Development Strategy

Build from reusable foundations into visible business capabilities, not a large collection of disconnected modules. The MVP must prove that a business can be modelled once and multiple useful applications and workflows can operate against that model.

All persistent and addressable categories must conform to objects and types, including business data, relationships, knowledge, configuration, permissions, workflows, independently addressable nodes, events and view definitions. A polished CRM over an incompatible foundation is not a successful MVP.

The first demonstrator is a generic Business-scoped Enquiry -> Qualification -> Decision -> Project flow, not a Spearmint Design Business, generic CRM or completion of the capability landscape. Build the minimum universal runtime needed to execute its bounded process. D01-D10 are settled; implementation details are specified in implementation architecture. Historical Spearmint references below are retained only as development provenance.

The existing marketing application is reusable implementation/UI material only. No migration, compatibility layer, old business-schema reconciliation or preservation of old functionality is required.

Foundation Gates

These gates are architectural requirements, not claims that a particular database, worker, test suite or user interface exists.

First Executable Milestone

A user can authenticate into Idiosyncrasy, enter an authorised Business context, inspect addressable objects, and perform a governed state-changing operation through Command -> Validation -> Authority/Policy -> Commit, with the resulting state change and provenance/history addressable.

Acceptance includes an inspectable Command, Action Execution, Attempt, changed object revision and state-transition occurrence with source/actor/authority references. Unauthorised, stale and duplicate requests cannot bypass the same path. Unknown outcomes remain explicit. UI/API/Workflow/AI adapters must use that authoritative mutation service; a fake AI or external adapter is sufficient for boundary tests, with no provider needed.

The initial UI/login foundation is part of the core model projection, not a later decoration. A working screen without these runtime guarantees does not meet the milestone. Neither does a backend that cannot be operated by an authorised human.

Implementation Priority

1. Core project/runtime structure: a modular monolith, distribution-ready by contract. 2. Persistence and authoritative object model. 3. Foundation-only Genesis and deterministic platform opening/release. 4. User registration and confirmation. 5. Authentication and authorization integration. 6. Ordinary platform-scoped business.create and Business context. 7. Object/relationship/state model. 8. Provenance/history. 9. Workflow/action execution foundation. 10. Basic UI shell and login. 11. IDY-008 Business-scoped demonstrator configuration. 12. First bounded IDY-009 demonstrator workflow. 13. IDY-010 Surface UI over the established foundation and demonstrator direction. 14. Tests proving the architectural invariants and the usable product surface.

Tests accompany each relevant step; the final item is the integrated proof gate, not permission to postpone authority or transaction tests. Keep incomplete mutation paths inaccessible until the complete validation/authority/history boundary works. The demonstrator does not depend on Genesis-created human or customer state. Its prerequisite chain is User registration -> confirmation -> authentication -> bounded onboarding authority -> ordinary business.create, after which IDY-008 installs configuration for the resulting Business. There is no special first Business and no implicit access to Spearmint.

Generic Business-Scoped Demonstrator

The intended lifecycle is:

Enquiry -> Qualification -> Project/Scoping -> Proposal
-> Internal Delivery Authorisation -> Design -> Design Acceptance
-> Development -> Review -> Final Acceptance -> Launch -> Handover -> Completion

Internal Delivery Authorisation, Design Acceptance and Final Acceptance are distinct business determinations. A smaller initial workflow must not merge them into one generic approved flag. Later stages remain specified but unbuilt until executable configuration and tests exist.

Chosen first bounded configuration: Enquiry -> Qualification -> Project/Scoping. Apply approved reusable Business-scoped configuration through IDY-008 only after an existing Business has been created through the ordinary governed business.create operation. The platform does not create or assume a Spearmint Design Business. The configuration may define authorised operator/reviewer roles, Person/Organisation types, Enquiry, Qualification and Project types, typed Relationships, versioned domain Policies and an addressable Workflow definition; it does not create the Business, User, Membership, grants or operational records. Business-specific vocabulary is configuration, not new foundational tables or a product-specific engine.

| Step | Minimum configuration and proof | |---|---| | Enquiry | An authorised operator records source, contact reference or explicit unmatched status, summary and received time. The creation Command records provenance; no public intake connector is required initially. | | Qualification | An operator records requirements and fit assessment. An authorised reviewer records a scoped Decision on the Enquiry revision. Missing evidence, conflicting Policy or absent authority blocks progression; rejection remains historical. | | Project/Scoping | A governed Action creates the Project and source/customer relationships only after the applicable positive qualification Decision. Required inputs include scope summary and assigned responsible user. Record the transition, Command/Attempt and outcome coherently. Duplicate delivery cannot create another Project. |

Business input fields and approval requirements above are initial demonstrator configuration, not universal rules for every Business. The current bounded implementation represents the required Types, States, Transition Definitions, Relationships, Operation Contracts, Policies and presentation affordances through existing Business-scoped generic mechanisms and invokes them through the governed Operation/Command surface. It does not provide public intake, AI execution or later lifecycle stages. Live launch/publishing remains outside the first bounded workflow.

IDY-010 — Surface UI

IDY-010 is the next major product-development stage after the frozen foundation and demonstrator sequence. It establishes a thin but genuinely usable Business-facing surface over the existing Idiosyncrasy foundation. It is not intended to be the finished interface.

The Surface UI is both a usable product surface and an instrument for product learning. It should let people use the platform with real interactions, exercise the object, relationship, presentation, governance and workflow machinery, expose usability and model problems, discover missing functionality, validate the model against real Business work and provide feedback for subsequent implementation stages. Its scope is intentionally refinable as actual use produces evidence.

The intended normal-runtime journey is:

Register -> Confirm -> Authenticate -> Create Business -> Enter Business

This does not imply that Genesis creates a User, Business, first Business or bootstrap administrator. The ordinary creation path remains User -> business.create -> Business, and the Surface UI must not invent a special starting Business.

The initial surface should be Business-facing, understandable without knowledge of the object graph, expressed in natural business concepts, navigable and contextual. It should expose useful object and relationship information, governed interaction, meaningful state and outcomes, and enough capability for real Business work while remaining extensible. Raw IDs, Types, Commands, Attempts, repositories and relationship mechanics are implementation concepts, not the normal user experience.

The initial interaction surface may include Business overview and selection, objects/records, relationships, state, configuration, workflows, knowledge, people/roles, settings and relevant history/evidence. This is a direction for a thin initial surface, not a claim that every area is complete in IDY-010.

IDY-010 should build on useful existing capability where appropriate, including login/authentication, page-builder/CMS work, generic object inspection, generic transition forms, presentation infrastructure, navigation, Business context handling and workflow-related surfaces. These are not automatically obsolete. The implementation should determine what to retain, adapt, extend, replace or keep as technical/diagnostic UI; wholesale replacement is not required.

The Surface UI is not a second mutation system. UI mutations must use the established governed mutation path, including CommandHandler, authorization, Policy and server-resolved Business context. UI controllers must not write directly to the database, bypass policy or workflow state rules, invent authority or accept client-defined Business identity where the server must resolve it.

The balance between generic/model-driven surfaces and purpose-built business interactions remains open for exploration. Generic object views, forms, relationships, state, reusable presentation and configuration surfaces may coexist with purpose-built interactions such as Business creation, Enquiry creation, Qualification, Decision and Project creation. IDY-010 use is intended to discover the useful balance rather than freeze it in advance.

The Business Graph remains the underlying source of truth. The Surface UI should present it through understandable concepts such as Customer, Contact, Enquiry, Qualification, Project, Product, Service, Invoice and Staff member without creating a separate rigid domain model merely to make the interface conventional.

The Surface UI should ultimately make the IDY-009 demonstrator usable through a normal Business-facing experience:

Enquiry -> Qualification -> Project/Scoping

That experience should make Enquiry creation and viewing, Qualification, review/Decision, approval or rejection, resulting Project creation where appropriate, and meaningful state/history/evidence understandable. IDY-009 implementation remains separate; IDY-010 defines the interface direction through which the demonstrator can eventually be exercised.

IDY-010 is deliberately open to refinement. Actual use may produce new or removed requirements, changed priorities, new UI patterns, changed domain boundaries and architectural questions. Those discoveries feed later PLAN/BUILD cycles and are not documentation failure.

The bounded IDY-010 demonstrator surface and Enquiry -> Qualification read/result journey are HTTP-verified by var/http-acceptance/idy010-result.json (69/69 HTTP acceptance — PASS, zero failures, zero runtime diagnostics, clean shutdown, 2026-09-19). The superseded 42/42 first increment and intermediate 67/67 BUILD report remain historical evidence; neither is the final result. IDY-010 implementation is closed at this bounded scope. The Surface is intentionally not a finished/full product UI, the full configured PHPUnit result remains UNKNOWN — the full configured PHPUnit run was previously stopped before producing a final summary., and broader Surface capabilities remain future/refinement work rather than IDY-010 closure blockers.

IDY-010+ Planning Boundary

IDY-010 is currently defined because its immediate purpose is clear: Surface UI and early product feedback. IDY-010+ are provisional future stages whose scope, ordering, boundaries and detailed architecture remain subject to exploration. Broad candidate areas may be recorded, but IDY-011 onward are not frozen commitments. Future stages may be split, combined, renamed or reordered, and this document must not invent detailed contracts, Operation identifiers, schemas, migrations, tests or implementation specifications for them.

The Surface UI should preserve future Business Configuration flexibility. A Business may use one domain, several domains, overlapping domains or an entirely different combination of capabilities. New capabilities should use the common Idiosyncrasy substrate rather than forcing the kernel to be redesigned around each discipline. This is an architectural direction to validate through implementation and use, not a completed design.

Future configuration and operation retain manual and optional AI-assisted paths. AI may eventually help understand a Business description, ask configuration questions, suggest objects, Types, relationships, workflows, configuration or useful domains. AI remains optional; no future AI implementation detail is frozen here, and the platform must remain useful without AI.

Broader Capability Priorities

The source phases below preserve broader product coverage, not the first executable implementation order. The priority list above supersedes their earlier sequencing, especially the placement of UI/login. They are not additional first-milestone deliverables.

Foundation Coverage

| Priority area | Initial proof | |---|---| | Identity/Permission | Users (authenticated accounts), business membership and access control under an explicitly chosen isolation model; no assumed legacy admin/client hierarchy. | | Object/Data | Define types and properties, create/read/update/delete objects where permitted, and validate typed values. | | Relationship | Link and navigate shared objects, preserve contextual data and support cross-capability use. | | Event | Identify business changes and provide contextual events that workflows can consume without capability-specific coupling. | | Workflow | Represent business processes, conditions, actions, state transitions, approvals and the agreed scope of scheduled work. |

Automation/Scheduling is a distinct responsibility owned with workflows, not an omitted requirement or an implied worker implementation. The initial mechanism supports bounded waits and one-time dispatch; more advanced scheduling remains later implementation depth under the same contract.

Knowledge and Interface Coverage

| Priority area | Initial proof | |---|---| | Knowledge | Documents, notes, policies, procedures, general information, business memory and contextual knowledge linked to business objects. | | View/UI | Human-usable forms, tables, detail views, dashboards and navigation configured from the model. | | Content | Website and marketing content, reusable content, pages and media represented within the shared model. |

Knowledge access and generated/configured interfaces must work without AI. Content representation does not decide a publishing backend or promise a complete native website builder.

Business Operation Coverage

| Priority area | Initial proof | |---|---| | Communication | Email, notifications, messaging, templates and communication history for the selected demonstrations. | | Integration | Bounded external service/API, webhook or synchronisation interactions after the internal model is stable. | | Analytics | Reports, metrics, dashboards and workflow measurement, including operational rather than marketing-only outcomes. |

Choose the smallest external surface needed to validate the business flow. A connector demonstration is not a commitment to a complete provider catalogue or old commercial support obligations.

Optional Intelligence Coverage

Add optional AI/Intelligence for natural-language interaction, content generation, analysis, recommendations, configuration assistance, knowledge retrieval and workflow assistance after the underlying human-operated capabilities work.

Introduce Evolution/Optimisation lightly and expand it progressively. A deterministic observation and reviewable suggestion can prove the improvement intent before sophisticated AI inference exists. This is not a reason to omit MVP success criterion 10.

These priorities cover the fourteen mapped responsibilities without prescribing fourteen implementation units. Advanced intelligence and optimisation can be later scope; useful no-AI operations are required throughout.

Representative Business Scope

| Candidate slice | Included concepts to demonstrate | |---|---| | Business Core | Organisation, people, customers, products/services, activities and documents shared across views and processes. | | CRM | Contacts, organisations, opportunities, interactions and customer history using those shared objects. | | Workflow | Triggers, conditions, actions, approvals and bounded waits under the settled execution contract. | | Knowledge | A business knowledge base, documents, notes, policies, customer-specific knowledge and permission-aware search/retrieval. | | CMS | Pages, content, media, reusable sections and forms; live publishing backends follow the first bounded milestone. | | Marketing | Campaigns, audiences, content and scheduled communications through a selected delivery surface. |

This is a broader capability cross-section, not six initial modules. The Spearmint process above controls the first demonstrator; these examples do not replace it with a generic CRM or require CMS/marketing implementation first.

Human-Operated First

Every major capability must be useful without AI before deep AI integration. An absent provider must not stop editing, approval, execution, retrieval or ordinary business operation.

| Area | Human/deterministic capability first | Optional assistance afterwards | |---|---|---| | Marketing | Campaign object, audience, content, scheduling, approvals, delivery and tracking. | Campaign/content generation, audience suggestions, performance analysis and optimisation suggestions. | | CMS | Pages, templates, blocks/components, media and publishing. | Page/copy generation, SEO suggestions and content restructuring. | | Workflows | Triggers, conditions, actions, state and execution. | Natural-language workflow creation, explanation and optimisation suggestions. |

Assistance must operate through the same validity and authority boundaries. An explicitly configured AI action can produce non-deterministic output, but the runtime must validate and authorize its use; no-AI business paths remain available.

Eleven MVP Success Criteria

These preserve all eleven product MVP criteria from source 03 section 10. They remain broader product acceptance, not eleven additional features required before the first executable milestone. Each requires demonstrable evidence; none is satisfied by documentation or an unrelated legacy screen.

1. A business can be represented without bespoke application code. Demonstrate business-specific terms, structure and behavior through readable types and configuration on the common runtime. 2. All persistent/addressable platform data uses the same id + type + value primitive. Inspect representative business objects, configuration, knowledge, workflows/nodes, events, relationships, permissions and views; none may introduce a competing foundation. 3. Objects and relationships are reusable across capabilities. Trace the same customer, related person/organisation and work through several business experiences without rekeying copies. 4. Workflows execute deterministically. Demonstrate explicit conditions, actions and outcomes with AI disabled; record any separately configured AI step as an external input rather than treating inference as deterministic truth. 5. Knowledge can exist outside structured data. Retain explanations, procedures or document-based knowledge without forcing all meaning into ordinary scalar properties. 6. Knowledge can be related to business objects. Retrieve applicable knowledge from its product, customer, project or policy context with provenance and access controls intact. 7. Interfaces can be generated/configured from the business model. Use model-based forms, lists or detail views that authorized humans can inspect and configure. 8. A new capability can be assembled from existing engines. Demonstrate a new business vocabulary and flow without a capability-specific foundation or unjustified new execution engine. 9. AI can assist without being required. Show a bounded assistance path and the equivalent useful business operation with no provider configured; unapproved output cannot execute. 10. The system can suggest improvements. Produce an evidence-linked suggestion, permit review and rejection or approval, and define how the resulting change will be measured. Sophisticated autonomous optimisation is not required. 11. Configuration remains readable and editable by humans and AI. Inspect, edit and validate the represented configuration; an AI edit has no special exemption from approval, permissions or validation.

Broader Conformance Examples

These preserved scenarios exercise reusable contracts; they do not compete with Spearmint as the chosen first demonstrator. Their broader product intent remains, with unproven criteria explicitly reported in implementation status. Do not implement every example before the first milestone works.

Explicit Initial Exclusions

Also outside an automatic MVP commitment: a complete portal suite, all communication channels, advanced route optimisation/dispatch, fully autonomous evolution, exhaustive analytics, and every CMS backend. These are possible later capabilities, not rejected product ambitions.

Also later scope, not part of the first executable milestone: the commercial model (Business subscription entitlement, Licensed and Guest Users, Business activation, the unsubscribed promotional preview, billing and pricing transitions). It is intended future architecture owned by subscriptions and entitlements; currently all Businesses are treated as active and no subscription enforcement is implemented. No restriction arising from it may be introduced into the current build or the bounded Spearmint Design process.

Long-Term Expansion and Evidence Gates

The intended expansion is Foundation -> Business model -> Knowledge -> Workflows -> Interfaces -> Core business capabilities -> Integrations -> AI assistance -> Optimisation -> New capabilities -> New reusable engines where genuinely necessary.

This is a product trajectory rather than a replacement for the phase dependencies above. The platform should become more capable for every business without depending architecturally on one customer's implementation.

Implement the settled D01-D10 contracts using the chosen mechanisms; do not seek new architecture decisions for ordinary implementation details. Prove the invariants and record results before claiming runtime enforcement. Live integrations, advanced scheduling, generalised composition and optional intelligence are progressive implementation depth after the bounded workflow, not reasons to defer its foundation.