← Back to directory

idy-008-contract.md

implementation/idy-008-contract.md · 52.0 KB · 2026-11-02 12:48

IDY-008 Reusable Business Configuration Contract

> Current authority notice: IDY-008 remains the generic governed > Business-scoped configuration installer. The Capability Application material > in this historical contract is superseded and non-normative. Current > provisioning uses ordinary Objects, Definitions, Operations, Relationships > and the recursive Dashboard-root Presentation Object graph; no Capability > Definition, Capability Instance or Capability-specific runtime path is > required or permitted.

Contract identifier: IDY-008-CONFIGURATION-V1

Version: 1.2

Status: GENERIC CONFIGURATION CONTRACT CURRENT; HISTORICAL CAPABILITY APPLICATION SECTIONS RETAINED FOR LINEAGE ONLY

Owner: reusable Business-scoped configuration installation contract; IDY-009 uses it for a neutral Enquiry -> Qualification -> Decision -> Project demonstrator.

Authority: This record is governed by the core object model and authority, canonical objects/types, business model, semantics, time/events, workflow, identity/governance, views/content, implementation architecture and development documents. implementation-plan.md is planning source material and does not replace this contract. This record does not create a new D-number.

Implementation gate: Generic implementation may proceed only within the reusable release and existing governed runtime boundaries defined here.

> Terminology supersession, 2026-11-02: "Principal" in this contract is superseded terminology for User. Principal is not a current architectural concept. Identifiers such as principal_id are legacy implementation details retained until a separately authorized migration (PRR-061). Contract semantics are otherwise unchanged, except that any statement treating automation or an integration as an independent identity or authority subject is superseded: automation operates under authority delegated by a User, with the technical executor recorded as execution provenance (see identity and governance).

Purpose and Invariants

The complete Business lifecycle has three distinct runtime phases:

1. Business creation: the governed business.create Operation creates the Business, administrator Membership, bootstrap AuthorityGrant/Policy and durable provenance atomically. 2. IDY-008 configuration installation: the authenticated installer applies reusable Business-scoped definitions and governed Operation Contracts, including create_enquiry, submit_qualification, decide_qualification and create_project_from_qualification. 3. Business operational initialization: after configuration installation, the generic runtime initializer invokes those installed Operations to create the initial operational Enquiry, Qualification, Decision and Project objects and their relationships for the existing Business.

IDY-008 does not itself contain or directly seed operational Business records. It defines and provisions the reusable configuration and Operations required for operational initialization. The generic initialization phase subsequently invokes those governed Operations through the normal mutation pathway. The absence of operational records from demonstrator.json is intentional; it does not mean that a newly initialized Demonstrator Business remains empty. Initialization is retry-safe/idempotent, uses Business-scoped authorization, and produces objects readable through the normal authorized object and relationship surfaces. It is generic runtime behavior, not a Spearmint-specific seed or branch.

Platform-owned Principal and Business Definitions used by the initialisation slice are foundational vocabulary, not Business-scoped IDY-008 operational declarations. IDY-008 remains the reusable Business configuration installer; it does not silently adopt a newer Definition, create an initialization execution or migrate existing instances. The initialization workflow consumes an applicable Definition revision after the existing Business boundary has been established.

IDY-008 is a governed installer for trusted, versioned, reusable Business-scoped configuration. Configuration is addressable typed data in the generic Idiosyncrasy runtime, not an application-specific foundation. The installation is a governed sequence of Commands submitted through the existing generic mutation boundary.

Configuration installation establishes or updates approved Business configuration in an existing Business; it does not by itself apply a Capability Definition, create operational records, or migrate existing Objects. Capability Definition application is the explicit IDY-008 operation defined below. Neither path creates identity or authority, and neither mutates a platform Definition.

Platform Definition publication and Business Definition application are separate activities. definition.publish creates or revises a reusable platform-owned Definition through the existing universal Object, exact-revision and provenance boundaries. IDY-008 applies an exact published Definition revision as a Business-owned Application; it is not the semantic publisher. Applying a Definition never mutates it. Publication availability requires successful evidence for the exact Definition Object revision; a manifest declaration, release, name or catalogue entry is not publication evidence. Product composition belongs to Business Capabilities, and no capability-specific publisher, graph, registry or store is introduced.

The existing demonstrator's capability_definition and capability_derivation declarations and eight revision-1 Business records are historical configuration and test evidence only. They are not complete Definitions or conforming Applications, are not application inputs, and must not be silently converted, rebound, overwritten or deleted. New Applications bind an exact published Definition Object ID and positive revision; release ID, version, digest and declaration ID remain configuration provenance, not substitutes for Object identity, revision or publication evidence. No legacy link is added unless an existing governed Relationship contract supports it; otherwise retained history is left untouched.

Historical Business Capability Application Contract (non-normative)

The Business Capability Application is an ordinary Business-owned Object of the retained Business Capability Instance Type at its new revision 2. Its Object ID is the application identity; its retained Object revision and history are the application revision/update history. Type revision 1 and its historical Business Objects remain unchanged. Revision 2 binds at minimum the server-resolved Business, exact platform Capability Definition Object ID and positive Object revision, lifecycle status, Business-specific terminology/configuration, and the exact publication identity evidenced for that Definition revision. It may carry selected/configured constituents only where the Definition permits Business selection, plus configured Operation, View and Form references at their exact applicable Object revisions. These are Object value and reference semantics, not a new persistence model. Provenance and creation/update history use the existing Command, Action Execution, Attempt, Outcome, Event, Object revision and provenance mechanisms; they are not an ungoverned duplicate payload.

The Definition states reusable capability composition and supported behavior. The Application states how one Business adopts/configures that exact revision. The Application cannot alter the platform Definition. Constituents required by the Definition are derived from its validated recursive composition; independently addressable constituents bind exact Object identity and revision, while values that do not require independent identity remain inline under the universal Object rules. Business-selectable constituents/configuration must be permitted by the Definition. Operation, View and Form references must resolve to the exact supported Object revisions declared or allowed by the Definition. A Definition or dependency with an omitted revision is invalid; no revision defaults to 1 or latest.

An IDY-008 Application request supplies the exact Definition Object ID and revision, requested/assigned Application Object identity through the existing Object identity mechanism, permitted Business-specific configuration/selections, exact Operation/View/Form bindings and the expected Application Object revision for an update. The target Business is resolved from authenticated server context, never trusted from request data. A create has no expected prior Application revision; an update must name the current expected Object revision. The request cannot nominate a release as a substitute for Definition identity, or use a manifest declaration, capability name or catalogue item to resolve one. Publication/release identity is retained from the verified evidence for the bound Definition revision where that evidence supplies it.

The application operation first resolves the exact platform-owned Definition revision, checks successful exact-revision publication evidence, and runs the bounded non-executing Definition composition validator. Before any mutation it validates Business existence/isolation and configuration authority, verifies all exact typed references and Definition-permitted selections, derives the required constituents, validates the resulting revision-2 Application value, and checks the expected Application Object revision. It then submits the application mutation through the existing IDY-008 generic CommandHandler path. That path performs the existing Membership, AuthorityGrant and Policy checks, expected-version enforcement, commit-time authorization recheck, transaction, Object revision and evidence writes. Application grants no authority and does not authorize configured Operations.

Replaying the same Command identity and semantic fingerprint returns/reconciles its prior result without duplicate effects. Reusing a Command identity with different content conflicts. Reapplying identical content to the same Application Object is idempotent; a different Definition binding or changed configuration cannot overwrite an existing Application unless an explicit update supplies its current expected Object revision. Distinct Application Object identities remain distinct ordinary Objects. Unpublished, stale/unavailable, omitted-revision or invalid Definitions; missing dependencies; cross-Business references; unpermitted selections; invalid Operation/View/Form revisions; missing authority; stale Application versions; conflicting identities; and indeterminate Command results fail closed or use existing reconciliation. No migration of operational Objects occurs implicitly.

The workspace demonstrator fixture is database/configuration/idy-008/demonstrator.json; it is test-trusted only and is not a production release. No production spearmint.json artifact is created by IDY-009. The trusted release top-level object contains exactly these fields: The artifact describes configuration content for an already-existing Business. The target Business is supplied by the authenticated, governed runtime context; the release is not intrinsically one tenant and its digest identifies release content, not a Business instance. Spearmint Design is the first real Business that will use this mechanism, but it is created through ordinary governed business.create before configuration installation. The release may define Business-owned Types, States, Transitions, Relationship Types, domain Policies, model-driven Views/Forms, Workflows and independently addressable Workflow Nodes. Workflow declarations bind complete Node identities to exact Node revisions and identify one entry Node; they do not embed a competing authoritative Node copy.

No specific Principal or Business is created as a side effect of platform installation or IDY-008 configuration installation. A Principal is created through normal runtime admission, and a Business is created through governed business.create. IDY-008 can only configure an already-existing Business. The release contains reusable configuration content only. It contains no target business_id, Principal identity, authority identity or identity_registry. Canonical bytes and the SHA-256 digest are therefore independent of the target Business. The authenticated, server-governed runtime context supplies the target Business at installation time. The Type model remains generic. Types are first-class addressable data and do not contain executable code. Configuration validation must fail closed for unsupported declaration kinds, executable configuration, invalid references, invalid dependencies and incomplete required declarations.

Release-Local Identity and Runtime Binding

The former tenant-bound scaffold used an identity_registry and literal target identities. That material is historical/superseded and is not part of the active release contract. A current release uses stable release-local declaration identities; installation derives deterministic runtime object identities from each declaration identity and the server-resolved Business. This permits the same release to be installed independently into multiple Businesses while keeping release digest bytes unchanged.

A release must not assign or provision a tenant, Principal or authority identity. Reviewer and workflow Principals, memberships and grants are outside the active configuration inventory unless a separately approved reference-only form is added. Seeded relationship instances are not configuration definitions and must not be inferred from a Relationship Type. The trusted release top-level object contains exactly manifest_id, version, release_id and declarations. The release digest covers release content, not a fixed Business instance.

manifest_id identifies the stable logical configuration lineage. version is the ordered configuration version. release_id identifies an immutable published manifest release. A changed manifest requires a new release_id and a higher version.

The manifest does not contain the authoritative expected digest. The trusted expected digest is held independently by first-party, code-controlled release verification, mapping approved release_id values to expected SHA-256 digests. The internal representation of that authority is an implementation detail and is not established by this contract. Canonical JSON is produced by recursively sorting object keys, preserving array order and preserving scalar types with deterministic encoding. SHA-256 is calculated over the canonical JSON bytes. Byte length is diagnostic only and is not an approval condition. The target Business is selected only from authenticated/server-governed runtime context. It must already exist with creator provenance and initial administration/governance. A release cannot nominate, create, select or authorize a Business. A business declaration is not an active declaration kind; any former scaffold use is historical/superseded. Installation must abort before mutation on: The active release recognizes only kinds compatible with reusable Business configuration:

The contract does not freeze a particular allowlist storage mechanism or CLI argument name. The declaration envelope, declaration kinds, dependency grammar, and deterministic Command-ID derivation are defined below.

The following are not active declaration kinds and are rejected unless a future contract amendment explicitly defines them:

The server-resolved Business must exist; installation cannot proceed when it does not, and the release must not be converted into an implicit bootstrap path. If governance is insufficient, installation cannot proceed and the release cannot self-create missing authority. Failed and unknown Commands remain observable. Unknown results require existing reconciliation handling and must not be blindly replayed. No separate recovery engine is introduced.

The installer requires an authenticated operator who is a normal governed runtime Principal after ordinary business.create. The server resolves the Principal and already-existing Business from durable identity/governance state. It verifies an active Membership, applicable AuthorityGrant, applicable Policy, dependency authority and current expected versions before admitting any installation Command. Release content contains no target Business identity and never grants authority. A missing Business or insufficient governance rejects installation; the release cannot create or bootstrap identity, Business or platform state. Foundation Genesis and the separate platform opening/release are prerequisites outside IDY-008.

Platform Semantic Concepts are optional reusable semantic knowledge. They are not mandatory parents or prerequisites for a Business Relationship Type. A Business Relationship Type remains valid and executable without a Platform Semantic Concept or semantic mapping.

A semantic mapping, where present, is an explicit, governed, traceable and versionable relationship between a Business Relationship Type and an applicable Platform Semantic Concept. It does not redefine the Business Relationship Type or change its runtime meaning. It may be absent, changed or removed without invalidating the Business Relationship Type or its Business-scoped relationship instances. Similar terminology does not establish a mapping, and an AI proposal is not authoritative configuration without deterministic validation and applicable approval.

Spearmint Relationship Type definitions, Platform Semantic Concepts and mappings are subject to stable identity, deterministic pre-mutation validation, Business isolation, endpoint compatibility, direction, cardinality, Policy, expected-version, provenance/history, governed Commands, per-Command atomicity, retry and Unknown/Reconciliation rules. This contract does not define a general semantic-knowledge system, ontology, inference mechanism or new generic operation. Relationship instances and their endpoint objects remain Business-scoped and do not grant authority.

Declaration Envelope and Scope

Every declaration is a strict object with exactly these common fields:

| Field | Requirement and semantics | | --- | --- | | id | Required lowercase UUIDv4. Literal persistent identity assigned by the release artifact; never generated during installation. | | kind | Required approved declaration-kind token. Operation/effect is derived from kind and value; no explicit operation field is permitted. | | scope | Required platform or business. It declares ownership, not authority. | | business_id | Forbidden in reusable release content. Business scope is supplied by the authenticated, server-governed runtime context. | | type_id | Required UUIDv4 of an existing authoritative Type definition. | | type_revision | Required positive integer identifying the exact Type revision. latest and implicit revisions are forbidden. | | value | Required JSON object validated against the exact type_id and type_revision. Kind-specific semantics belong here. | | dependencies | Required array, possibly empty, containing only the dependency forms defined below. | | classification | Optional strict non-executable JSON object where permitted by the kind. It is descriptive metadata, not authority or executable configuration. |

Unknown envelope fields, duplicate IDs, incompatible identity reuse, executable configuration and unresolved references reject before mutation. Every envelope field, value, dependency and classification contributes to the manifest digest. All semantic fields contribute to the derived Command identity when they affect the compiled effect.

The target Business is selected only from authenticated/server-governed runtime context. It must already exist with creator provenance and initial administration/governance. A release cannot nominate, create, select or authorize a Business. A business declaration is not an active declaration kind; former tenant-bound scaffold text is historical/superseded.

Declaration Kinds and Identity Boundary

The active release recognizes only kinds compatible with reusable Business configuration:

| Kind | Ownership and scope | Required Type/reference | Command effect | | --- | --- | --- | --- | | type | Business-owned domain vocabulary | Type-of-Type model | object.create or approved exact-version object.update | | state | Business | Existing State Definition Type | object.create | | transition | Business | Existing Transition Definition Type | object.create | | relationship_type | Business | Existing relationship vocabulary | object.create | | policy | Business | Existing Policy Type | object.create or approved exact-version object.update | | view | Business | Existing View Definition Type | object.create or approved exact-version object.update | | form | Business | Existing Form Definition Type | object.create or approved exact-version object.update | | workflow | Business | Existing Workflow Definition Type | object.create or approved exact-version object.update | | workflow_node | Business | Existing Workflow Node Type | object.create |

The following are not active declaration kinds and are rejected unless a future contract amendment explicitly defines them:

Identity lifecycle, credentials, authentication state, Memberships, AuthorityGrants and human/runtime authority are separate governed operations. Domain Policy declarations may configure Business behaviour, but cannot bootstrap installation authority.

Platform vocabulary objects established by IDY-003 through IDY-007C are prerequisite references, not IDY-008 declarations. IDY-008 must not create competing copies of those objects.

All active declarations are Business-scoped after runtime binding. Cross-Business references are forbidden except references to approved platform prerequisites.

Platform Vocabulary Prerequisites

IDY-008 references the authoritative platform vocabulary established by earlier stages. It does not redeclare or replace:

Where required, IDY-008 records the prerequisite release identity, version, digest and exact Type revision as a dependency/reference. The installer must not create a competing platform object or alter the ownership, schema or revision semantics of IDY-003 through IDY-007C.

Dependency Grammar and Ordering

Every dependency is exactly one of these strict objects:

{"kind":"object","id":"<uuid-v4>","revision":1,"expected_type":"<uuid-v4>"}

or:

{"kind":"release","release_id":"<approved-release>","version":1,"digest":"<sha256-hex>"}

An object dependency is satisfied only when the referenced Object exists at the exact revision, its authoritative Type matches the mandatory expected_type, and it satisfies the applicable scope and Business ownership rules. latest, omitted revisions, inferred versions and omitted expected_type are forbidden. Operation dependency eligibility and exact-revision availability are owned by the Operation Contract; this manifest contract does not expand that exhaustive allowlist.

A release dependency is satisfied for manifest installation only when the exact release, version and digest are installed or independently verified by the authoritative runtime bootstrap mechanism. A release dependency is not executable through Operation dependency resolution until an authoritative release verifier exists. This contract does not create that verifier.

Missing, mismatched, conflicting, retired or unavailable dependencies reject before mutation. Cycles, cross-Business dependencies and dependencies on undeclared future state reject before mutation. Declarations are ordered by a deterministic topological sort; independent declarations are tie-broken by canonical lowercase UUID. Dependency order does not grant authority; every Command repeats current authorization, Policy, dependency and expected-version checks.

This pre-mutation rejection is specific to a manifest's declared release/declaration dependency graph. It must not be conflated with a runtime workflow dependency that becomes unresolved after configuration is installed or object conditions change. Runtime unresolved dependencies follow Workflows and automation: they are classified as conditions, may produce Events and may invoke an explicitly configured resolution workflow, request an authorized human, select a configured alternative or pause. Neither path permits invented data or inferred authority.

Business creation is an external prerequisite to IDY-008. Creator provenance and initial Business administration/governance are established by the separate governed Business-creation capability. The target Business must exist before installation validation can succeed. The phase order below remains for configuration declarations evaluated against that existing Business:

Configuration declarations are dependency-ordered as follows; identity and authority entries are references only and are never provisioning steps:

Business binding against existing runtime Business
-> references to existing Principals/Memberships/Grants, where permitted
-> foundational Types/States
-> domain Types/States
-> Relationships
-> Policies
-> Views/Forms
-> Workflow
-> Workflow nodes

Pre-Mutation Validation Barrier

No mutation of any kind may occur until complete manifest validation has succeeded. Read-only inspection of existing runtime state is permitted during validation.

Before installation validation can succeed, the server-resolved target Business must already exist; its creator provenance and initial administration/governance must already be established by the separate governed Business-creation capability. The resolved installer must already have an active Membership, applicable AuthorityGrant and applicable Policy for the target Business. Release declarations cannot self-authorize installation or create missing Business governance.

The normative validation sequence is:

1. Parse JSON and validate the exact root structure. 2. Validate the supported manifest version. 3. Validate the release identity and canonicalization rule. 4. Canonicalize the manifest and calculate its SHA-256 digest. 5. Resolve the trusted release/digest allowlist and compare the trusted expected digest. 6. Validate prerequisite release dependencies. 7. Validate declaration identity and UUID uniqueness. 8. Validate declaration kind and strict envelope fields. 9. Validate scope and Business ownership. 10. Resolve exact Type identities and Type revisions. 11. Validate the dependency graph, missing references, conflicts and cycles. 12. Validate classifications and typed values. 13. Validate the existing server-resolved target Business and governance context, then validate Business isolation and reject identity, authority and operational declarations. 14. Validate relationship endpoints, direction, cardinality and integrity. 15. Validate View and Form fields, renderers, relationships and operations. 16. Validate Workflow Definitions and exact Workflow Node IDs and revisions. 17. Validate entry Node membership, graph references and reachability. 18. Validate all cross-declaration references and duplicate/conflicting declarations. 19. Classify existing state and durable Command evidence for reconciliation. 20. Compile declarations to existing generic Command envelopes. 21. Validate every compiled Command. 22. Derive deterministic Command IDs. 23. Prepare final current-state authority and expected-version checks. 24. Admit the first Command.

Commit-time authorization, Policy, dependency and expected-version checks still execute against current authoritative state. Pre-mutation validation is not a substitute for commit-time checks.

Command and Mutation Model

IDY-008 uses the existing generic Command/mutation boundary. Its future Operation Contract declarations are addressable typed configuration consumed by fixed trusted handlers under the Operation Contract. All consequential configuration mutations use the existing Command service. No separate Spearmint mutation engine may be created, and repositories must not be written directly as an alternative mutation path.

The four bounded Spearmint Operations, create_enquiry, submit_qualification, decide_qualification and create_project_from_qualification, are reusable business capabilities represented by Operation Contract Objects. Their fixed handlers construct one governed Command per invocation; they do not expose a caller-defined effect list, executable configuration or a new mutation primitive. The generic object.create, object.update, object.relate and object.transition effects remain runtime-owned implementation details of that Command boundary.

Configuration is installed as a governed sequence of individually atomic Commands. There is no requirement for one giant manifest transaction. Each Command:

Earlier successful Commands remain committed if a later Command fails. A failed or incomplete installation must not be reported as a complete manifest installation.

Matching duplicate delivery of a committed Command is idempotent and is treated as already applied. Reusing the same Command identity with changed semantic content is a fingerprint conflict. Stale expected versions are rejected without a second revision or semantic effect. An unknown result is not treated as failure or success without inspection; it enters the existing Unknown/Reconciliation handling.

Deterministic Command Identity

IDY-008 uses derived Command IDs. Declarations must not contain an explicit command_id field.

Before constructing the existing Command envelope, the installer constructs a canonical pre-ID semantic basis containing exactly the applicable:

The basis excludes the Command ID, timestamps, process and worker IDs, filesystem paths, declaration position, installation attempt, transport metadata, formatting and whitespace. Object keys are recursively sorted, array order is preserved where semantic, and scalar types are preserved.

The derived identity is calculated using:

SHA-256(domain_separator || derivation_rule_version || canonical_pre_id_basis)

The domain separator is the ASCII byte sequence idy-008-command-id-v1, and the derivation-rule version is the ASCII value 1. The first 16 bytes of the SHA-256 digest are copied into a 16-byte UUID value; the version nibble is set to 4, the variant bits are set to RFC 4122 variant 10, and the result is rendered as lowercase hexadecimal UUID text. The derivation is deterministic, independent of installation attempt and independent of runtime time. Identical semantic declarations produce identical Command IDs. Declaration formatting and ordering cannot change identity, and retries cannot change identity.

The derived ID is then inserted into the existing Command envelope. CommandCanonicalizer remains responsible for the final Command semantic fingerprint. An existing Command ID with different semantic content or fingerprint is rejected as a conflict. The cryptographic collision expectation is that of SHA-256; a detected identity or fingerprint collision is still rejected, never merged.

Bounded Spearmint Vocabulary

The approved Spearmint operation vocabulary is exactly:

decide_qualification supports approved and rejected determinations. There is no separate eligibility Command.

submit_qualification creates a Qualification, relates it to the Enquiry, transitions the Enquiry to qualification_submitted and records qualification.submitted.

decide_qualification records the reviewer decision, transitions Qualification to approved or rejected and records qualification.decided. A rejected decision transitions the Enquiry to rejected and ends the bounded workflow. A positive decision makes the workflow eligible for project creation.

create_project_from_qualification is permitted only after the applicable positive Qualification decision. Its Command rechecks the exact decision and relevant object, Policy, authority and dependency revisions before creating the Project and required relationships, transitioning the Enquiry to scoped and recording the required provenance, Event, state transition and Outcome evidence. Duplicate delivery must not create another active Project for the same Qualification.

The Qualification and Project consequences remain governed mutations. An approved decision does not itself grant missing authority, bypass validation or authorize a later Command without a fresh commit-time recheck.

Reconciliation States

An installation is classified as exactly one of:

not_installed proceeds only after the complete validation barrier. already_installed reports success without duplicate effects. partial may resume only from deterministically classified unresolved work using existing Command, Attempt, Outcome and history evidence. conflicting, drifted, invalid and dependency_failure reject without silent overwrite or bypass.

Identical existing state is recognized using deterministic Business-scoped runtime identity, exact Type and revision, Business ownership and canonical value. The server-resolved Business must exist; installation cannot proceed when it does not, and the release must not become an implicit bootstrap path. If governance is insufficient, installation cannot proceed and the release cannot self-create missing authority. Failed and unknown Commands remain observable. Unknown results require existing reconciliation handling and must not be blindly replayed. No separate recovery engine is introduced.

Pending declaration-level reconciliation contract

The existing installer has no governed action for intentionally accepting a changed persisted declaration value. Its drifted result is therefore fail-closed by design. The existing platform.install_configuration authorization and the DefinitionApplicationOperationHandler do not cover this case: the former installs the trusted release as a whole, and the latter applies a Definition Object rather than reconciling an IDY-008 declaration. The generic Command service supplies the required update, locking, expected version, history, provenance and retry primitives, but it is not by itself an approval to use them for drift acceptance.

The pending Operation proposal is platform.reconcile_configuration_declaration, candidate ID 9f4f6b8c-3d2e-4f10-8a11-22334455669a, revision 1, with trusted handler key platform.configuration.reconcile-declaration. The identity and handler are not allocated or implemented. The canonical semantic proposal, including inputs, authority, target validation, Command identity, transaction, idempotency, concurrency, evidence, failure rules and tests, is owned by the Operation Contract. No code or STAGING operation is authorized by this section.

The smallest conforming action is one independently authorized, one-object object.update Command for one exact declaration. The handler must load the trusted release declaration rather than accept a caller-defined replacement, resolve the Business from authenticated context and require an exact match on declaration runtime identity, Type identity/revision, Business, current Object version and inspected persisted-value digest. It must reject stale, changed, conflicting, unauthorized, dependency-invalid or already-different state without mutation. Matching retries use the existing deterministic IDY-008 Command identity and fingerprint; changed content under the same identity is a conflict. Several declarations require separate Commands and separate expected-version checks.

The proposed authority should be distinct from ordinary installation authority, because accepting intentional drift is a narrower and more consequential action than admitting an approved release. Whether a new AuthorityGrant operation is required or the existing configuration authority is explicitly approved for this action is an owner decision. A trusted handler registration, exact Operation identity and any CLI-only invocation adapter require the same separate approval.

The STAGING execution procedure is also pending: read-only snapshot and redacted evidence; approved release/digest and target verification; explicit authenticated invocation per declaration; retained Command/Object/provenance evidence; normal installer already_installed result; unrelated-state comparison; and an idempotent repeat with no new revision. This task stops before all of those mutation steps.

Invocation Boundary and CLI Authority

The first IDY-008 implementation target is the existing build-target CLI, following the conventions of genesis.php and runtime-vocabulary.php. It is a Business configuration installation capability, not a Business-creation capability and not an administrative HTTP configuration endpoint.

The Business creation sequence is separate from installation:

authorised Principal -> Business creation capability -> Business identity -> creator provenance -> initial administration -> Membership / AuthorityGrant / Policy -> IDY-008 becomes eligible

The installation authority sequence is:

Authenticated Principal -> existing governed Business -> existing Membership -> existing AuthorityGrant -> applicable Policy -> IDY-008 installation

These are architectural and governance boundaries, not a requirement for separate user sessions or products.

The installer must:

1. load the approved release content; 2. verify its trusted release_id and canonical SHA-256 digest; 3. resolve the operator/executor Principal server-side; 4. resolve the already-existing Business server-side from the authenticated installation context; 5. verify the existing active Membership; 6. verify the existing scoped configuration authority; 7. apply applicable Policies; 8. validate the complete declaration graph; 9. submit configuration mutations through the existing Command service; and 10. report Command statuses and reconciliation state.

The existing generic POST /commands remains an ordinary caller surface. It is not required to be the IDY-008 installation interface.

The installer requires an authenticated operator who is a normal governed runtime Principal after ordinary business.create. The server resolves the Principal and already-existing Business from durable identity/governance state. It verifies an active Membership, applicable AuthorityGrant, applicable Policy, dependency authority and current expected versions before admitting any installation Command. The manifest business_id is an identity reference only and never grants authority. A missing Business or insufficient governance rejects installation; the manifest cannot create or bootstrap identity, Business or platform state. Foundation Genesis and the separate platform opening/release are prerequisites outside IDY-008.

The manifest must not contain passwords, credentials, authentication tokens, hard-coded authority bypasses or development credentials. A reusable release contains no fixed production Principal or Business identity. The authenticated runtime context supplies the Business binding and installation authority; the release cannot grant either.

The existing architecture does not define a CLI authentication adapter. The concrete adapter and operator-selection mechanism remain an implementation-boundary decision to resolve before implementation; they must reuse the existing identity and governance model and must not create a second identity system. This is not permission to weaken the security invariants above.

Retry, Reinstall and Reconciliation

For the same release, reinstall or continuation reuses declaration IDs, Command IDs and fingerprints. Matching committed Commands are treated as already applied. Unknown or incomplete Commands must be inspected before continuation; they must never be blindly replayed. Continuation resumes from unresolved dependencies where the existing evidence permits safe continuation. Conflicts are rejected.

A newer release uses new Commands and current expected versions. It cannot overwrite or erase prior history. Configuration revisions remain addressable and historical records remain retained through the existing object/revision model.

Partial failure must record, through the existing infrastructure:

Reconciliation settles or classifies existing durable Command/Attempt evidence under the existing authorization boundary. It does not erase an unknown attempt or authorize unsafe blind replay.

Declaration-level drift acceptance, if approved, is a separate explicit reconciliation Operation and is not a hidden branch of reinstall. It must revalidate the inspected persisted-value digest and expected Object version at commit time, preserve the prior revision and provenance, and leave all unselected declarations unchanged. A release installer must continue to reject drifted until that Operation has settled the exact declaration.

Authorization and Business Isolation

The target is a distinct existing Business. Spearmint Design is one runtime Business using this generic path. Every configuration Command resolves the Business server-side and verifies:

Client-supplied Principal, Business, membership, grant or Policy values cannot grant authority. Sharing and cross-Business access are not inferred. Inaccessible objects or configuration must not be disclosed.

Configuration authority is distinct from the operator/reviewer distinction in the Spearmint registry. The latter does not alter universal runtime authorization semantics.

Provenance and History

Every configuration mutation remains traceable through the existing provenance and history mechanisms to the applicable evidence for that operation, including, where applicable:

Business creation provenance is evidence produced by the separate governed Business-creation capability. IDY-008 installation provenance identifies the authenticated installer Principal, target Business, manifest ID/version, release ID, trusted/verified digest, declaration, derived Command ID and fingerprint, relevant dependencies and exact Type, Policy, Workflow and Node revisions. Installation provenance must not describe the installer as the Business creator, permanent administrator or owner unless independent existing evidence establishes that fact. Configuration does not introduce a second audit ledger. Objects, revisions, Commands and required evidence remain addressable and retained according to the existing generic runtime contracts.

The installation provenance must retain, where applicable, the manifest ID, manifest version, release ID, manifest-calculated digest, declaration ID and kind, authenticated Principal, Business, derived Command ID and fingerprint, Action Execution, Attempt, Outcome, Event, state transition, and exact Type, Policy, Workflow, Node and dependency revisions. Installation attempts and failures remain observable through these existing structures; no separate provenance subsystem is introduced.

First-Release Inventory Boundary

The first-release artifact must distinguish required platform prerequisites, required Spearmint configuration and conditional configuration. The following inventory is normative as a boundary, not a populated manifest:

Required platform prerequisites

Existing IDY-003 through IDY-007C Type, State, View/Form, Workflow Definition/Node, Command, Attempt, Outcome, Provenance, Event, transition, relationship and dispatch evidence vocabulary. These are referenced by exact release/version/digest and Type revision where required; they are never redeclared by IDY-008.

Required configuration boundary

The exact declaration inventory and semantic field definitions are product-owned release content and must be approved before an artifact is created. This boundary describes configuration definitions, not operational records. Enquiries, Qualifications, Projects, People, Organisations, customers, staff and transactions are normal runtime Business data and are not silently seeded by IDY-008; where an approved generic initialization phase is required, it creates them only through governed Operations after configuration installation.

Conditional configuration

The following remain conditional and must not be inferred as required:

Conditional items require explicit inclusion in the approved release inventory and stable literal identities if included. No UUID, release ID, digest, credential, operator identity or Business ID is assigned by this contract.

Scope and Explicit Exclusions

IDY-008 includes:

The following are explicitly excluded:

The manifest remains configuration-only. The generic initialization runtime, its trusted Operation handlers and its tests are implementation evidence governed by this contract; they do not add operational records to the manifest or create a second seed architecture.

The former fixed business_id, tenant-specific identity_registry and identity declaration effects are historical/superseded scaffold material. The production artifact path remains unpopulated and the production trust map remains empty until a concrete approved release exists. None of this permits provisioning a Business, Principal or authority during installation; those remain Business-creation responsibilities before configuration and operational initialization.