Settled Architecture Decisions

Status: D01-D10 SETTLED AND CLOSED, confirmed by the project owner on 2026-09-11. Implementation is not thereby built or verified. This record supersedes the previous register's open-question classifications and conflicting topic numbering.

Authority and Evidence

Use this precedence: explicit final architecture decisions in the supplied transcript and subsequent explicit project-owner corrections; consistent canonical documentation; repository decisions not superseded; necessary implementation specification. Implementation mechanisms cannot redefine semantic contracts.

The supplied transcript contains selected final-decision passages. The project owner's subsequent correction explicitly confirms D01-D10 as complete and supplies persistence, retry, policy composition, bootstrap, deployment and demonstrator direction. The source ledger records that evidence separately: statements from the correction must not be attributed to missing transcript passages.

No new architecture decision numbers are introduced. The old register's D04 Time, D05 Policy and D10 Documentation Ownership labels, among others, were repository routing labels, not the final titles. The headings below use the authoritative final titles supplied by the project owner during the audit. Those titles and semantic routes are known even where the local transcript omits detailed earlier clauses; absent wording is not invented. Documentation maintenance belongs to documentation governance, not another numbered architecture decision.

D01 - Identity, Business Context & Authority

Status: SETTLED AND CLOSED. Identity and governance owns Identity, authentication, Business context, Authority, Approval, isolation and delegation. These distinctions and their authoritative enforcement apply across UI, API, workflows, workers and AI. The local excerpt does not reproduce every original clause; that provenance limitation does not change the known title, ownership or settled status.

D02 - Object Identity, Types & Addressability

Status: SETTLED AND CLOSED. Objects and types owns object identity, first-class Types, addressable State definitions and the distinction between semantic objects and primitive values. The excerpt references D02.8's addressable transition occurrences; time and events owns their historical meaning. Full earlier clauses are not reproduced in the local excerpt.

D03 - Graph Semantics

Status: SETTLED AND CLOSED. The supplied Graph summary and D03.9 approval establish explicit relationship semantics, type-defined constraints, contextual/temporal applicability, provenance-aware derivation and non-destructive assertions. Business model is the definition owner. Connectivity grants neither authority nor semantic inference.

D04 - Policy

Status: SETTLED AND CLOSED. The project owner's correction establishes addressable, versioned Policies; explicit dependency, refinement, exception and supersession relationships; governed contextual composition; preserved conflicts; defined deterministic resolution or an authorised human determination; addressable/auditable resolution. Semantics owns composition and identity and governance owns enforcement. A relationship alone does not establish precedence.

D05 - Workflow & Execution Semantics

Status: SETTLED AND CLOSED. Workflows and automation owns Workflow Definition, Workflow Step, Workflow Execution, Action, Action Execution, Attempt, Outcome and Effect distinctions, with Event/history meaning in time and events. D05.29 establishes authoritative Action preconditions and commit-time rechecks. D05.83-D05.84 establish scope-preserving materialised determinations and their independent lifecycle under AI. The project owner's correction confirms explicit retained Attempts, deterministic safe-repeat semantics and governed recovery before repeating unsafe/unknown effects.

D06 - Recovery, Resumption & Operational Integrity

Status: SETTLED AND CLOSED. Workflows and automation owns recovery, resumption, migration, re-entry and compensation contracts; time and events owns preservation of their historical evidence. Interruption does not invent business outcomes or erase execution identity, prior definition bindings or Attempts. Implementation architecture and operations specify mechanisms separately. Omitted detailed source passages do not reopen the contract.

D07 - Technical Runtime, Persistence & System Integrity

Status: SETTLED AND CLOSED. The project owner's correction establishes durable authoritative persistence, coherent required state/history commit, explicit-version optimistic concurrency, stale-incompatible rejection, non-authoritative projections/caches, explicit Unknown/Reconciliation and stable Command identity under duplicate delivery. D07.24 supplies explicit scoped attributable delegation. Semantic owners: objects and types, workflows and automation, time and events and identity and governance. Implementation architecture specifies mechanisms, not alternative meanings.

D08 - Configuration, Definition & Extensibility

Status: SETTLED AND CLOSED. Product definition owns extensibility and its non-overridable foundational boundary. Objects and types owns definition validity and Business model owns business-specific configuration assembly. Businesses may define previously unanticipated concepts within the universal runtime, not redefine its foundational enforcement semantics. Demonstrator scope remains separately owned by the roadmap; it is not the meaning of D08.

D09 - Presentation, UI & Interaction Architecture

Status: SETTLED AND CLOSED. Views and content owns model-projection UI, view/form definitions and the distinction between interaction state and authoritative business State. Identity, Business context, Authority, object, State and workflow context shape the permitted interface; UI and AI interfaces invoke the same governed runtime rather than supplying alternative business semantics. UI system specifies presentation mechanisms. Backend delivery is an integration concern, not the meaning of D09.

D10 - Knowledge, Information & Semantic Understanding

Status: SETTLED AND CLOSED. All six Knowledge principles are explicitly approved in the transcript: first-class same-model knowledge; documents as sources rather than automatic truth; contextual applicability; governed AI participation; authorised retrieval; non-destructive evolution. Definitions belong to knowledge, with retrieval and AI owning their respective boundaries.

Confirmed Cross-Cutting Direction

The project owner confirms foundation-only Genesis, separate platform opening, User-first admission, model-projection UI, AI authority boundaries, workflow/recovery and distributed execution semantics as settled. The initial runtime is a modular monolith, distribution-ready by contract. Genesis creates no human/customer runtime state, there is no special first Business, and Spearmint Design is the first demonstrator scenario created through ordinary business.create.

The roadmap owns the first milestone and bounded process. The implementation specification chooses the smallest mechanisms to enforce it. Implementation status alone records built and verified evidence. No generic CRM, microservices, automatic external exactly-once guarantee or old-data migration obligation is implied.

The core object model and authority records the cross-cutting invariants reconciled from the project owner's 2026-09-23 platform discovery. It does not replace any D01-D10 owner, alter their settled meaning or create D11.

The implementation closure for the initial Business boundary preserves that direction: business.create establishes only Business-Type inspection for the newly created Business plus the separate platform.install_configuration authority targeting TYPE_OF_TYPE. Machine inspection is independent of View/Form Definitions, which remain presentation/configuration and cannot grant authority. The legacy FOUNDATION_VIEW artifact is not part of the settled runtime contract, and foundation-only Genesis remains unchanged.

Unnumbered Cross-Cutting Clarification - Four Semantic Object Roles

Status: APPROVED CONCEPTUAL FOUNDATION. This clarification is recorded under D02 Object Identity, Types & Addressability, D03 Graph Semantics, D05 Workflow & Execution Semantics, D07 Technical Runtime, Persistence & System Integrity, D08 Configuration, Definition & Extensibility and D09 Presentation, UI & Interaction Architecture. It does not create D11 or any new architecture decision number.

Idiosyncrasy has exactly four semantic object roles: Data, Logic, Workflow and Presentation. These roles express the business meaning of objects within the existing universal object model; they are not values of the D02 Type system. The type continues to identify domain meaning, so Types such as Business, Customer, Invoice and Workflow Definition remain valid. Infrastructure records such as Event, Command, Attempt and Outcome remain addressable same-model records. Complexity is expressed by recursively composing the four roles.

A Data Object's current value may be a concrete value or an object reference to Data, Logic, Workflow or Presentation. The reference is the value itself; it is not a permanent initializer, computed-field relationship or execution instruction. When a concrete value is required, contextual dependency traversal may inspect the reference and determine whether Data is available, another dependency must be inspected, a Workflow interaction is required, an explicit governed operation is required, or the dependency is missing, inaccessible, unavailable, unresolved or incompatible. Traversal itself does not execute Workflow or Logic; any required execution uses current authority and Policy validation, Command admission and normal Attempt/Outcome/Provenance/Event evidence. A later governed mutation may replace the reference with a concrete value or another reference. Revisions retain historical explanation without being embedded in the current value.

Workflow, Logic and Presentation may contain one another. Data may reference any of the four, while structural Relationships continue to use the existing Relationship contract where independent identity, endpoints, metadata, provenance, history or lifecycle are required. Search, requests, inputs, calculations, queries, automation, configuration, To Dos and AI assistance do not create additional semantic roles. Workflow Definitions, executions, Events and other infrastructure records remain addressable same-model records under their existing owners; their existence does not contradict the four-role model.

Dependency resolution is a platform capability and a contextual runtime walk, not a semantic object type or persisted dependency-state graph. The absence of a concrete value does not require universal Data Object states such as PENDING, BLOCKED or RESOLVED. Execution conditions remain distinguishable where required by the Workflow contract, while UI tasks and To Dos remain projections of Workflow objects.

Authority remains orthogonal: a reference does not grant permission to discover, execute, modify, participate in or approve its target. Mutation remains governed through the existing path. AI remains optional and cannot introduce an AI/Intelligence/Knowledge/Agent semantic role. External effects remain within Command -> Attempt -> Outcome -> Provenance/Event; cycles and concurrency remain execution/mutation concerns requiring bounded, future implementation contracts.

The detailed semantic contract, canonical examples and invariants are owned by core object model and authority. This clarification confirms and sharpens existing decisions; it does not authorize new tables, object classes, resolver subsystems, state machines, workflow engines, logic engines, APIs, AI services or database changes.

Unnumbered Cross-Cutting Amendment - Foundation and User-First Opening

Status: APPROVED AND FROZEN. This amendment is under the settled D01-D10 governance structure and does not create D11. Terminology supersession, 2026-11-02: "Principal" in this frozen amendment is superseded terminology for User (see the owner-correction note below); the contract semantics are otherwise unchanged.

Foundation-only Genesis installs generic object/revision prerequisites, Type-of-Type semantics, minimum foundational Types, required Genesis occurrence/ledger semantics, deterministic manifest verification, fresh-store refusal, idempotent installation/conflict detection and non-human technical installation provenance. It creates no human User, credential, identity, Business, Membership, Business AuthorityGrant, Business Policy, owner, superuser, permanent administrator, first Business, customer View or permanent human runtime actor. The resulting customer/runtime state is empty.

Platform opening is a separate deterministic release/configuration, not Genesis, a second pseudo-Genesis or generalized IDY-008. It may install identity-lifecycle Operation descriptors and trusted handlers, confirmation/onboarding rules, the platform business.create Operation, active platform Policy and technical release evidence without creating human state or continuing authority.

The frozen normal lifecycle is registration -> confirmation -> authentication -> bounded onboarding -> business.create. Registration creates only server-owned pending identity, normalized association, separate credential material and a protected challenge. Confirmation is a narrowly bounded single-use challenge transition that issues only a revocable User-bound platform grant for business.create against Type Business; it does not grant general administration or create a Business. business.create remains ordinary governed runtime and creates initial Business governance atomically. IDY-008 remains strictly Business-scoped configuration installation. IDY-009 depends on this lifecycle and ordinary creation of Spearmint Design.

Unnumbered Cross-Cutting Clarification — Relationship Type Ownership

Status: APPROVED. This clarification is recorded under D03 Graph Semantics and D08 Configuration, Definition & Extensibility. It does not create a new D-number.

Decision: Idiosyncrasy adopts Option C: Business-owned Relationship Types, optional Platform Semantic Concepts and governed semantic mappings.

A Business Relationship Type belongs to one Business and defines that Business's relationship meaning, terminology and applicable endpoint, direction, cardinality, slot, lifecycle and integrity semantics. It is versioned and historically traceable, remains independently valid and usable without a Platform Semantic Concept or mapping, and is governed by the Business subject to platform-wide invariants. Its application remains subject to the governed operation/workflow boundary; the Type itself is not a Workflow or Logic execution instruction.

The platform may maintain optional reusable Platform Semantic Concepts as semantic knowledge. They are not mandatory parent Types, prerequisites, hidden global ontology or sources of Business runtime authority. Business Relationship Types and Platform Semantic Concepts may evolve independently.

A semantic mapping is explicit, governed, traceable and versionable where required. It does not redefine or constrain the Business Relationship Type, may be absent or removed without invalidating the Type or its instances, and cannot be inferred from similar terminology. AI may propose a mapping, but the proposal is not authoritative until it passes deterministic validation and applicable approval.

Business authority governs Business-owned Relationship Types and their domain use. Platform authority continues to govern universal object identity, Business isolation, authorization, security, universal relationship integrity, Platform Semantic Concepts and applicable platform-level semantic governance. Exact approval roles and any mapping-specific approval requirement remain open governance details.

This clarification changes no D01-D10 invariant, generic mutation boundary, workflow contract or implementation mechanism. It preserves the principle that sophisticated governed model data may be presented through progressively simpler representations without simplifying the underlying authority model. The separate Workflow Node reconciliation remains unaffected.

Unnumbered Cross-Cutting Amendment — Fenced Execution Finalization

Status: APPROVED WITH RUNTIME EVIDENCE LIMITATION. This is an implementation-contract correction under the settled D01-D10 architecture; it does not create D11 or any new numbered architecture decision.

Problem: The frozen Stage 1 lease release() operation supports only WorkflowExecution running -> eligible and workflow_dispatch claimed -> eligible. Stage 2 also needs to leave a valid leased execution in waiting, succeeded, failed, suspended, or reconciliation_required while clearing lease ownership. Direct Stage 2 writes would bypass the Stage 1 fencing boundary.

Decision: Approve one additional narrowly scoped Stage 1 lease-bound operation:

finalizeLeasedExecution(execution_id, dispatch_id, worker_id, lease_token, target_state)

The permitted target states are exactly waiting, succeeded, failed, suspended, and reconciliation_required. This operation is not a general WorkflowExecution state mutation facility and does not replace or generalize release().

Required preconditions: The operation must verify, inside the existing coordination and transaction boundary, that the WorkflowExecution and dispatch row exist; their identities match; dispatch is claimed; the authoritative WorkflowExecution is running; the exact lease token and worker identity match; the lease is unexpired; Business identities are consistent; the expected current WorkflowExecution revision is current; current authorization requirements are satisfied; and the target state is in the exact permitted set.

Atomic result: On success, the same finalization transaction changes WorkflowExecution running -> target_state, changes dispatch claimed -> the corresponding non-claimed state, clears lease token, worker identity and lease expiry, and commits all required state changes together. Any rejected or failed precondition produces no mutation. Stale, expired, wrong-worker, wrong-token, wrong-state, stale-revision, cross-Business, unauthorized and unsupported-target requests fail closed.

Existing release: release() remains unchanged and continues to perform ordinary continuation through running -> eligible and claimed -> eligible. Stage 2 uses release() for ordinary continuation and finalizeLeasedExecution() only when leaving running for one of the five permitted target states.

Waiting wake: waiting -> eligible remains a separate operation with no active worker lease assumed. It must not be implemented by treating a finalization lease as still active.

Expiry: Lease expiry continues to fence the old worker and does not automatically reclaim, finalize, resume or replay execution.

Stage 2 expiry scope: IDY-007C Stage 2 does not implement expired-lease re-eligibility or any operation that changes an expired claimed/running execution to eligible. Expiry leaves the old execution and dispatch fenced and unresolved for this stage. Stage 2 may preserve and inspect durable evidence and may perform only reconciliation operations already authorized by the existing Command/Attempt contract; such reconciliation does not authorize re-eligibility, lease clearing, replay, retry, or resumption of the expired WorkflowExecution. Any future transition from this fenced state to eligible requires a separately governed recovery capability. This deferral does not alter release(), finalizeLeasedExecution(), or the 100-step counter.

Evidence boundary: Stage 2 persists required StepAttempt, Outcome and related evidence before calling finalization. finalizeLeasedExecution() atomically finalizes WorkflowExecution, dispatch and lease metadata only; it does not claim an arbitrary shared PDO transaction with Stage 2 evidence unless a later implementation provides and proves one. A crash between evidence persistence and finalization is handled through durable evidence and later governed recovery/reconciliation.

Command boundary: CommandHandler retains its existing transaction ownership. Stage 2 cannot enclose CommandHandler in one PDO transaction; stable Command identity precedes invocation; conclusive results permit continuation; uncertain results require reconciliation_required; unknown work is never blindly replayed.

Scope and exclusions: This amendment changes no 007A or 007B semantics, introduces no cancellation operation, automatic recovery, retry, worker substitution, User substitution, queue, scheduler, interpreter or node behavior, and does not make lease metadata authoritative business state.

Unnumbered Cross-Cutting Amendment - Temporal Meaning, Correction and Reconstruction Boundary

Status: APPROVED AND FROZEN. This amendment records the temporal contract established by the completed architecture exercise under the settled D01-D10 governance structure. It does not create D11 or alter any existing numbered decision.

The platform preserves the distinction recorded_at != occurred_at != business-effective time. Recorded time is platform recording time, occurrence time is reported occurrence time, and business-effective time is domain-specific. Effective intervals are not universal fields, a late-arriving fact retains its recording time separately from any known occurrence/effective time, and unknown effective time remains unknown.

Retained object revisions provide reconstruction of retained recorded history. Where the existing evidence model records them, consequential operations retain the exact definitions, policies, workflows, Operations and their revisions, actors, authority context and inputs used. Corrections are attributable new information and must not silently overwrite historical assertions; supersession changes current standing or operative use and is not deletion. Future capabilities must declare their required temporal/reconstruction guarantee.

This contract does not promise universal bitemporal storage, event sourcing, automatic replay or complete reconstruction of every derived historical state. It does not introduce a universal effective_at column or a temporal subsystem. The canonical temporal meaning and correction boundary is owned by time and events; implementation status remains separate.

Unnumbered Cross-Cutting Amendment - Reference Authority and Bounded Dependency Resolution

Status: APPROVED AND FROZEN. This amendment records the reference/dependency contract established by the completed architecture exercise under the settled D01-D10 governance structure. It does not create D11 or alter any existing numbered decision.

The fundamental invariant is REFERENCE != DEPENDENCY != EXECUTION != AUTHORITY. A Data value may reference Data, Workflow or Logic. A reference identifies a value/object relationship and grants no read, discovery, traversal, execution, modification, participation or approval authority. Structural Relationships remain separate where the connection requires independently addressable endpoints, meaning, direction/role, cardinality where applicable, metadata, lifecycle, provenance, history or applicability; ordinary value references are not silently converted into Relationships.

The exact-revision Operation dependency allowlist remains frozen. Dependencies do not silently rebind to newer revisions, recursively become another Operation, inherit authority, bypass authorization or become implicit execution instructions. Retrieval traverses only authorized, contractually permitted references or Relationships; inaccessible targets must not be disclosed through visible sources, and Business isolation applies throughout.

Future generic traversal must be bounded by visited object/revision/path tracking, maximum depth, node and edge limits, and evaluation/execution budgets. Cycles and budget exhaustion produce explicit evidence and a bounded outcome such as pause, reject or escalate; no universal CIRCULAR Data state is introduced. Missing, inaccessible, unavailable, unresolved, incompatible and execution-failure conditions remain distinct. Retrieval/traversal never implicitly executes Workflow or Logic; execution requires an explicit governed operation/workflow action, current authority/Policy validation, Command admission and retained evidence.

The canonical reference, authority and bounded-resolution boundary is owned by core object model and authority, with exact Operation dependencies owned by Operation Contract and execution/retrieval details remaining with their existing owners. This amendment introduces no new dependency resolver and no new semantic type.

Unnumbered Cross-Cutting Clarification - External Action Authority Subject

Status: APPROVED AND FROZEN, 2026-09-30. This clarification records Stu's explicit direction to authorize an external Action against its governed Operation Contract/Operation identity. It sits under the settled D01-D10 structure and creates no D11 or other architecture decision number.

An external Action with no local mutation target is authorized against the exact Operation Object identity. Reuse the existing Business Membership, AuthorityGrant and Policy model: the Grant targets the Operation Type and exact Operation Object ID, and the active Policy matches that same Operation identity and name. The Operation reference is not authority. Resolve and retain the exact Operation revision, then recheck that revision and current Grant/Policy under the existing Command boundary. Do not infer authority from a Business Type, Connection, Action Execution or other convenient target, and do not introduce a Connection Type, special Action authority subsystem or parallel permission model.

The first supported external Action is send_email through a trusted no-network simulation Provider. Simulation is explicitly not sending, remote acceptance, delivery or recipient interaction. Live provider effects and asynchronous delivery remain deferred. Identity and Governance, Operation Contract, Communication and Integrations, and implementation status own the semantic, invocation, provider and evidence details respectively.

Unnumbered Cross-Cutting Correction - User Replaces Principal

Status: PROJECT-OWNER CORRECTION, 2026-11-02. This is an owner correction under the settled D01-D10 structure. It creates no D11 or other architecture decision number and leaves the D01-D10 headings and meanings unchanged. Explicit project-owner corrections supersede conflicting repository prose under documentation governance.

There is no separate Principal concept. The platform identity and authority subject is the User: an authenticated account that signs into Idiosyncrasy. A Person is an individual profile defined within the context of one Business; a User may be associated with a Person in a Business, and neither requires the other. Authentication, Membership and AuthorityGrant reference User. Automation, workflows and integrations have no independent identity or authority; they operate under authority delegated by a User, with the technical executor recorded as execution provenance (the detailed execution, succession and revocation model is unresolved).

The existing persisted Type is named Principal, but its records represent User accounts. Principal is a legacy implementation identifier, not a current architectural concept or a separate identity Type. Existing Type names, object identifiers, database columns and code identifiers remain as legacy implementation details until a separately authorized migration, which is blocked by Stage 3D (PRR-002) and tracked as PRR-061. Where this correction conflicts with the wording of an earlier frozen amendment, contract or historical record, the earlier text carries an explicit supersession note and is otherwise unchanged. Details: identity and governance, implementation architecture.

The same correction session recorded the intended commercial model (Business subscriptions only; free User registration and Business creation; Licensed Users counted, Guests free and unable to execute Business operations) as intended future architecture, owned by subscriptions and entitlements. It is not implemented: all Businesses are currently treated as active.

Reading Implementation Specifications

Keep three separate statements: settled semantic contract, chosen implementation mechanism, current implementation status. A stable Command identity is a contract; a unique database index is a mechanism; deduplication not yet built is a status. Missing code, physical layout details or original source wording do not reopen D01-D10. Reasonable implementation details are specified in existing implementation owners, not promoted into new architecture decisions.

Platform Governance Foundation Build Status

The approved platform/business scope model is now represented in the runtime as an explicit scope abstraction. Platform AuthorityGrant and Policy resolution are direct-User (persisted as the legacy Principal Type), exact-scope and fail-closed; Business Membership remains Business-scoped and neither scope inherits authority from the other. The trusted business.create handler is registered as a server-owned plan producer, while Genesis authority remains confined to Genesis.

This is implementation status, not a new decision number. The platform CommandHandler branch, nullable platform evidence descriptor revision and atomic bootstrap execution remain incomplete and must be verified before the approved business.create contract is called executable.

decisions.md