← Back to directory

README.md

README.md · 12.2 KB · 2026-11-02 12:48

Idiosyncrasy Documentation

Status: current navigation and authority map, 2026-10-28. This index routes to definitions; it does not independently define architecture or claim implementation completeness.

Start Here

Read product definition for the business-adaptive platform, core object model and authority for the cross-cutting semantic invariants, architecture overview for the responsibility map, and roadmap for the first executable milestone, Spearmint Design demonstrator and provisional IDY-010 Surface UI direction. D01-D10 are settled architecture. Consult implementation status before relying on working functionality.

The current specification takes precedence over the earlier marketing application. Existing code is reusable material only, not a migration or backward-compatibility obligation. Documentation governance controls authority and status; the source ledger records preservation and supersession.

Authority Map

| Subject | Sole definition owner | |---|---| | Product purpose, principles, ownership, product-composition language, extensibility test | Product definition | | Product-composition examples and cross-business scenarios | Product definition and Business capabilities | | MVP scope, human-first sequence, success criteria, future boundaries | Roadmap | | Universal addressable primitive, authoritative durable state, types, validity and foundation-only controlled genesis | Objects and types | | Cross-cutting object, definition, derived State, history, workflow-boundary and authority invariants | Core object model and authority | | Business Graph, relationships, Assertions/applicability, Business DNA | Business model | | User-first identity lifecycle, Business identity, creation provenance, administration and authority lifecycle | Identity and governance and Business model | | Subscription state, entitlement, commercial model (Licensed and Guest counting), Business activation and operational gate (intended future architecture; not implemented) | Subscriptions and entitlements | | Rule, Policy, Constraint, Goal, Decision | Semantics | | Operation Contract, Operation Invocation and its boundary to Command, Policy and evidence | Operation Contract | | Event, time, versions, history, causal and audit evidence | Time and events | | Knowledge, institutional memory, provenance and epistemic authority | Knowledge | | Structured-first platform retrieval and derived indexes | Retrieval | | Workflow, Command, Action Execution, Attempt, commit, concurrency, retry/recovery and distribution contracts | Workflows and automation | | User, Person, Licensed and Guest User, Business-scoped isolation, permission, approval, delegation, autonomy/risk enforcement | Identity and governance | | Model-driven applications, views, forms, content, media and variants | Views and content | | Communication, notification, integration, adapter and normalized tool contracts | Communication and integrations | | Analytics, measurement, optimisation and evolution | Analytics and evolution | | Optional AI, provider/output boundary and materialised validation determinations | AI |

The overview maps fourteen responsibilities to these owners, not fourteen software modules. Cross-cutting owners cooperate: types declare valid structure, governance authorizes, workflows execute, views render and time/history provides historical meaning. Summaries defer to those contracts.

Implementation and Build Guidance

Implementation is developed from the checked-out local workspace and synchronized through the GitHub repository StuMayne74/Idiosyncrasy. Local runtime files, credentials, databases and generated release state remain outside the tracked source boundary; see development for the evidence rules.

| Document | Use | |---|---| | Implementation architecture | Chosen runtime mechanisms and implementation boundaries; bounded Definition publication, generic persisted presentation projection and the simulation-only Action foundation are implemented, while broader runtime work remains deferred. See status for evidence. | | IDY-007C execution contract | Frozen approved contract for bounded sequential workflow execution, dispatch leases, node evidence and recovery; the bounded IDY-007 Slice 1 lease/finalization path is implemented and verified, while the broader workflow runtime and deferred recovery capabilities remain incomplete. | | IDY-008 configuration contract | Approved contract for reusable Business-scoped configuration integrity, governed Commands, dependency ordering and reconciliation; the Capability Application boundary and persisted Business bindings are implemented, while broader Spearmint configuration remains incomplete and the historical capability fixture is not Definition authority. | | Operation Contract | Frozen reusable business-capability contract consumed by View, Workflow, API and AI invocation surfaces; bounded invocation, generic Definition publication, exact Operation-identity Action authorization and no-network send_email simulation are implemented, while broader runtime/release coverage remains incomplete. | | UI system | Reusable visual and interaction baseline, responsive/component patterns and limitations. | | Security and operations | Security requirements, configuration, secrets, deployment and verification knowledge. | | Development | Scoped build workflow, engineering conventions and actual available checks. | | Implementation status | New-platform evidence separated from earlier-code reuse dispositions; current Definition/Application verification is distinct from historical IDY-010 evidence and incomplete full-suite results. | | Readiness register | Authoritative register of temporary decisions, deferred capabilities, known defects, gaps and production-readiness risks with revisit triggers and closing evidence, plus the production-readiness gap assessment. It records; it does not define architecture or declare readiness. | | Stage 3D owner decision request | External handoff recording the architecture decision for platform Type-revision authority; it does not authorize implementation or production access. | | Stage 3D production evidence request | External handoff for the pending authorized, read-only production Type/dependency inventory; it does not authorize access. | | WordPress | Backend-specific discovery, tools, draft delivery and operational knowledge; not a platform-wide dependency. |

Task-Oriented Reading

Use this route for a bounded implementation task; do not read the documentation tree in full:

| Task | Canonical meaning | Implementation mechanism | Current evidence | |---|---|---|---| | Object, Type, State or authority semantics | Core Object Model plus the owner in the Authority Map | Implementation architecture | Implementation status | | View, form or Object Presentation behavior | Views and Content; cross-cutting Object Presentation remains owned by Core Object Model | Implementation architecture, UI system and the relevant implementation contract | Implementation status | | Operation, Command or workflow behavior | The linked owner in the Authority Map and applicable D01-D10 decision | The applicable frozen contract, then Implementation architecture | Implementation status | | Security, deployment or verification | Identity and Governance or Security and Operations | Development and Security and Operations | Implementation status | | Build sequencing only | Roadmap and settled decisions | Only the relevant section of Implementation Plan, with section 24.1 as the current executable order | Implementation status |

The required reading order is:

Task
  ↓
Authority Map
  ↓
Relevant canonical contract
  ↓
Relevant implementation mechanism or frozen contract
  ↓
Relevant status evidence
  ↓
Actual code and targeted verification

Archived, reference and historical material is for traceability only unless the task explicitly requires it. The Implementation Plan is planning guidance, not architecture authority, and must not be read in full for a bounded task.

Governance and Provenance

Reading Order and Status

For architecture: product -> overview -> objects/types -> business model, semantics, time and governance -> knowledge/retrieval -> workflow, views and integrations -> analytics/evolution and AI. Read only the prerequisites relevant to a task; each owner provides local context and links.

For build work: follow settled semantic contracts, the chosen implementation mechanisms, relevant UI/operations/backend guidance and invariant tests. Do not use old source code to redefine the model or treat missing implementation as undecided architecture.

"SETTLED" identifies approved architecture. "SPECIFIED" identifies its chosen implementation mechanism. "NOT BUILT" and "VERIFIED" concern implementation evidence only. "Later" is scope, not weaker authority. "Reference" and "superseded" are nonnormative. Do not add architecture decision numbers or reopen D01-D10 for implementation details.