Establish CommerceCanon draft kernel and foundation layout

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a070b5-4994-7271-bd8b-7c3dbcedec4b

AGENTS.md

@@ -208,7 +208,7 @@ anything needing analysis, design, approval, dependencies, or multiple phases.
 id: COMMERCE-WP-NNNN
 type: workplan
 title: "..."
-domain: infotech
+domain: financials
 repo: commerce-canon
 status: proposed | ready | active | blocked | backlog | finished | archived
 owner: codex
@@ -242,8 +242,8 @@ Status progression: `todo` → `progress` → `done`; use `wait` for waiting/blo
 
 To create a new workplan:
 1. Write the file following the format above
-2. Notify the custodian operator to run `make fix-consistency REPO=commerce-canon`
-   (or send a message to the hub agent via `POST /messages/`)
+2. Run `uv run --project ~/repo-manager rmgr sync --path . --push` as specified
+   in the session-close protocol above.
 
 
 ## CommerceCanon workplan prefix and provenance

README.md

@@ -13,4 +13,6 @@ models pass their canon review gates; the rename alone does not publish them.
 Start with [INTENT.md](INTENT.md), [SCOPE.md](SCOPE.md), the
 [research corpus](research/CorpusIndex.md), and [workplans](workplans/).
 The [migration ledger](../prj-canon-federation/ledger/README.md) records concept
-destinations. The new canon layout is tracked by CFED-WP-0001-T04.
+destinations. Start with the draft [kernel](infospace/kernel/CommerceCanonCore.md),
+[registry](canon.yaml), and [layout assessment](docs/RepositoryLayout.md).
+The model registries remain empty pending CFED-WP-0001-T05/T06/T11.

SCOPE.md

@@ -24,9 +24,9 @@ CUST-ADR-006. Its shared technical concepts are imported from InfoTechCanon.
 ## Migration status
 
 The repository rename preserves history. The old mixed glossary remains a
-migration input until CFED-WP-0001-T04/T05/T06/T07 establish the destination
-layout, models, and provenance distribution. Rename completion does not imply
-those publication gates have passed.
+migration input. T04 establishes the draft kernel and directory layout;
+CFED-WP-0001-T05/T06/T07/T11 still own model publication and provenance
+distribution. The scaffold does not imply those publication gates have passed.
 
 See INTENT.md, research/CorpusIndex.md, and the federation ledger. New plans use
 COMMERCE-WP-; existing IDENTITY-WP identifiers and finished files remain intact.

assimilation/README.md

@@ -0,0 +1,4 @@
+# Assimilation entry point
+
+CommerceCanon keeps canon content under [infospace/assimilation](../infospace/assimilation/).
+This root entry point is a navigation aid, not a second content registry.

canon.yaml

@@ -0,0 +1,29 @@
+repository: commerce-canon
+title: CommerceCanon
+status: draft
+version: 0.1.0-draft
+description: Counterparty and commercial-relationship semantics importing shared InfoTechCanon concepts.
+classification:
+  kernel: Canon purpose, ownership boundary, and contribution rules.
+  models: Domain concepts and relationships with declared upstream imports.
+  standards: Normative requirements over registered models.
+layout:
+  layout_family: kernel-models-standards
+  infospace_root: infospace/
+  documentation_conformance: core
+  documentation_standard: itc-repo-layout:RepositoryLayoutStandard
+  documentation_standard_version: 0.1.0-RC1
+  documentation_standard_source_commit: b081d39da1353201f879ee6832d4e3e52b791c73
+  assessment: docs/RepositoryLayout.md
+kernel:
+  - id: commerce-core
+    title: CommerceCanon Core
+    path: infospace/kernel/CommerceCanonCore.md
+    status: draft
+models: []
+standards: []
+planned_models:
+  - ledger_locator: counterparty
+    status: awaiting-model-migration
+    work_item: CFED-WP-0001-T06
+    prerequisites: [CFED-WP-0001-T05, CFED-WP-0001-T11]

demand/README.md

@@ -0,0 +1,10 @@
+# Demand
+
+Record raw consumer signals here before analysis or workplan acceptance. A signal
+is not an approved task or a published concept. No new consumer demand is asserted
+by the foundation scaffold.
+
+Each signal should record a date, named consumer/repository, source reference,
+observed problem and concrete example, desired outcome, and unresolved questions.
+Set its status to unreviewed. Link the resulting local workplan after review;
+retain the original signal and distinguish assumptions from consumer evidence.

docs/README.md

@@ -0,0 +1,4 @@
+# Documentation
+
+[Repository layout and conformance](RepositoryLayout.md) describes the current
+structure, source references, migration exceptions, and validation.

docs/RepositoryLayout.md

@@ -0,0 +1,40 @@
+# Repository layout and conformance
+
+The foundation targets **core documentation conformance** to
+[InfoTechCanonRepositoryLayoutStandard](../../info-tech-canon/infospace/standards/repository-layout/InfoTechCanonRepositoryLayoutStandard.md)
+`itc-repo-layout:RepositoryLayoutStandard`, 0.1.0-RC1 (RC1-seed), reviewed at
+InfoTechCanon commit `b081d39da1353201f879ee6832d4e3e52b791c73`.
+That standard governs documentation placement; its section 9 does not prescribe
+canon domain-content layout. The kernel/models/standards tree follows the
+federation T04 requirement and InfoTechCanon's current canon.yaml layout family.
+
+| Requirement | Current evidence |
+| --- | --- |
+| Minimal: repository purpose and boundary | INTENT.md and SCOPE.md |
+| Core: raw demand distinct from implementation | demand/README.md and workplans/ |
+| Core: current stakeholder documentation | docs/README.md and this assessment |
+| Canon registry and ownership boundary | canon.yaml and infospace/kernel/CommerceCanonCore.md |
+| Canon extension locations | infospace/{models,standards,assimilation,mappings,concepts,profiles,patterns,validation}/README.md |
+
+Canon artifacts live under infospace/. Root assimilation/, mappings/, profiles/
+are navigation entry points to that single tree, satisfying the project goal's
+root discovery locations without duplicating content. Legacy canon/ and model/
+remain migration inputs. Registry models and standards are intentionally empty.
+
+Full documentation conformance is not claimed: research/history retain legacy
+names, and spec/, wiki/, issues/ are not established. Finished IDENTITY-WP files
+remain unchanged in workplans/ as required by the accepted migration provenance
+rule, rather than being moved to history/. T07 owns source distribution. This
+assessment does not claim that those models, provenance transfers, or interface
+cards have been accepted.
+
+## Validation
+
+Parse canon.yaml as YAML and check that each registered artifact exists and its
+frontmatter ID/status matches the registry; check that the core documentation
+files and all nine infospace directories exist. Verify relative Markdown links
+in the new scaffold against a sibling federation/InfoTechCanon checkout. Compare
+legacy source and finished-plan SHA-256 hashes with the pre-scaffold snapshot.
+Run the federation ownership validator against this repository and git diff
+--check. The project records the results under docs/evidence/; the native
+COMMERCE-WP-0001 links that evidence and the live migration tasks.

infospace/assimilation/README.md

@@ -0,0 +1,3 @@
+# Assimilation
+
+Canon assimilation practice and destination provenance indexes belong here. The existing research/, terminology/, and scenarios/ trees remain source material; CFED-WP-0001-T07 owns their recorded distribution.

infospace/concepts/README.md

@@ -0,0 +1,3 @@
+# Concepts
+
+Standalone concept cards belong here only when their owning model is declared. Do not copy the mixed legacy glossary into this directory.

infospace/kernel/CommerceCanonCore.md

@@ -0,0 +1,75 @@
+---
+id: commerce-core
+title: CommerceCanon Core
+status: draft
+version: 0.1.0-draft
+---
+
+# CommerceCanon Core
+
+CommerceCanon owns counterparty and commercial-relationship semantics. It is
+an independently maintained domain canon governed by Custodian canon and the
+accepted CUST-ADR-006 ownership resolutions. This draft kernel establishes the
+repository boundary; it does not publish the pending counterparty model.
+
+## Authority and migration
+
+The [federation ledger](../../../prj-canon-federation/ledger/README.md) assigns
+one owner per concept and pins the original identity-canon glossary. The old
+[glossary](../../canon/CanonicalGlossary.md) and
+[principles](../../canon/DesignPrinciples.md) remain migration inputs, not an
+alternative registry of CommerceCanon-owned definitions. The
+[registry](../../canon.yaml) lists only artifacts present here; its model and
+standard registries remain empty until their publication tasks are verified.
+
+## Ownership boundary
+
+| Concept or concept family | Owning model | CommerceCanon treatment |
+| --- | --- | --- |
+| Actor, Person, Agent, Organization, Group, Role, Membership, Ownership | itc-org | Import; commercial roles do not replace actor or ownership semantics. |
+| Subject, Principal, Relationship Tuple | itc-access | Import; commercial binding does not grant authorization. |
+| Obligation, Decision, AssuranceCase, AssuranceConclusion, Audit | itc-gov | Import; a commercial commitment may relate to obligations without redefining them. |
+| Identifier, Account, Scope, Assurance Level and ledger-assigned identity concepts | itc-ident (pending T05) | Import when published; identifier specializations retain upstream identity semantics. |
+| Evidence, Evidence Source, Adjudication Outcome, general evidence strength | itc-evid (pending T11) | Import assertions and their addressable sources as distinct concepts. |
+| Community, Household | itc-org extension (pending T12) | Import distinct social collectives when available. |
+| Family | Separate InfoTechCanon concept-area seed (pending T13) | Reference only; not a CommerceCanon collective-actor definition. |
+
+Existing upstream models are [organization](../../../info-tech-canon/infospace/models/organization/InfoTechCanonOrganizationModel.md),
+[access control](../../../info-tech-canon/infospace/models/access-control/InfoTechCanonAccessControlModel.md),
+and [governance](../../../info-tech-canon/infospace/models/governance/InfoTechCanonGovernanceModel.md).
+Evidence currently appears in governance; accepted R3/R7 assigns its transfer to
+T11. This table records the accepted destination, not a completed transfer.
+T05 must also reconcile Delegation Relationship with itc-org Delegation before
+publication. Nothing in this kernel resolves that open review by duplication.
+
+There is no single imported concept called “Assurance” covering all uses.
+Identity Assurance Level is distinct from governance AssuranceCase and
+AssuranceConclusion. The pending Counterparty Assurance Gradient is CommerceCanon's
+named application of general evidence strength, not ownership of that dimension.
+
+## Commerce model boundary
+
+T06 will author the ledger's commerce assignments: legal entities and persons,
+beneficial ownership relationships and exemptions, customer and vendor roles,
+commercial relationships and commitments, payment references and mandates,
+pipeline pursuits, commercial records, counterparty assurance, reputation and
+performance assertions, and registry/proxy commercial identifiers. These are
+assignments for migration, not definitions supplied by this kernel.
+
+Registry Identifier and Proxy Commercial Identifier specialize imported
+Identifier. Reputation Signal, Performance Evidence, and Beneficial Ownership
+Exemption must distinguish evidence assertions from their sources. Adjudication
+Outcome remains imported from itc-evid. Carry P14 (separate commercial records
+from accounts) and P15 (model commercial binding explicitly) into T06.
+
+## Contribution and acceptance
+
+New content starts with a named consumer's signal in [demand](../../demand/).
+Implementation belongs in repository workplans. A model must declare its owned
+concepts, explicit imports, provenance, and examples before registry publication.
+Validate assignments against the federation ledger and review for duplicate
+ownership. Preserve historical source material until T07 records its disposition.
+
+[Repository layout](../../docs/RepositoryLayout.md) explains content placement.
+T08 owns reciprocal interface cards once models and imports are established.
+Runtime services, a CLI, and production APIs are outside this foundation scope.

infospace/kernel/README.md

@@ -0,0 +1,3 @@
+# Kernel
+
+Purpose, ownership boundary, and contribution rules. Start with [CommerceCanonCore.md](CommerceCanonCore.md).

infospace/mappings/README.md

@@ -0,0 +1,3 @@
+# Mappings
+
+Mappings between external vocabularies and registered concepts belong here. State direction, source versions, and semantic losses; a mapping does not transfer ownership.

infospace/models/README.md

@@ -0,0 +1,3 @@
+# Models
+
+Domain models belong here with explicit owned concepts and imports. No model is published yet; CFED-WP-0001-T06 owns the counterparty migration.

infospace/patterns/README.md

@@ -0,0 +1,3 @@
+# Patterns
+
+Reusable arrangements of registered concepts belong here, with context and worked examples. Patterns do not create competing definitions.

infospace/profiles/README.md

@@ -0,0 +1,3 @@
+# Profiles
+
+Consumer-specific constraints over imported or owned models belong here. A profile must name its base models and demand evidence.

infospace/standards/README.md

@@ -0,0 +1,3 @@
+# Standards
+
+Normative requirements over registered domain models belong here. No CommerceCanon standard is published yet.

infospace/validation/README.md

@@ -0,0 +1,3 @@
+# Validation
+
+Model validation rules and worked acceptance cases belong here as models arrive. Foundation layout checks are recorded in docs/RepositoryLayout.md; no domain validation suite exists yet.

mappings/README.md

@@ -0,0 +1,4 @@
+# Mappings entry point
+
+CommerceCanon keeps canon content under [infospace/mappings](../infospace/mappings/).
+This root entry point is a navigation aid, not a second content registry.

profiles/README.md

@@ -0,0 +1,4 @@
+# Profiles entry point
+
+CommerceCanon keeps canon content under [infospace/profiles](../infospace/profiles/).
+This root entry point is a navigation aid, not a second content registry.

workplans/COMMERCE-WP-0001-foundation-layout.md

@@ -0,0 +1,68 @@
+---
+id: COMMERCE-WP-0001
+type: workplan
+title: "CommerceCanon foundation layout and kernel boundary"
+domain: financials
+repo: commerce-canon
+status: finished
+owner: codex
+topic_slug: commerce-canon
+created: "2026-09-05"
+updated: "2026-09-05"
+---
+
+# CommerceCanon foundation layout and kernel boundary
+
+Implements [CFED-WP-0001-T04](../../prj-canon-federation/workplans/CFED-WP-0001-foundation.md)
+after the in-place rename. Scope is a draft kernel and honest registry plus core
+documentation conformance; domain model publication remains separate.
+
+## Establish the registry and directory guidance
+
+```task
+id: COMMERCE-WP-0001-T01
+status: done
+priority: medium
+```
+
+Add canon.yaml, the nine infospace categories, root discovery links, demand and
+docs. Keep source research and finished IDENTITY-WP plans unchanged.
+
+## Record ownership and migration boundaries
+
+```task
+id: COMMERCE-WP-0001-T02
+status: done
+priority: high
+```
+
+Draft commerce-core from accepted ADR-006 and the ledger, identifying pending
+upstream publications and separating identity/governance/commercial assurance.
+No service surface or speculative model registration.
+
+## Verify and reconcile the foundation
+
+```task
+id: COMMERCE-WP-0001-T03
+status: done
+priority: medium
+```
+
+Check registry integrity, core layout, links, preserved source hashes and ledger;
+publish and reconcile the workplan, with project evidence and live residual links.
+
+## Live continuation records
+
+The project workplan remains active. CFED-WP-0001-T05 and T11 own the upstream
+identity and evidence prerequisites; T06 owns counterparty model publication;
+T07 owns corpus disposition; T08 owns interface cards; T12/T13 own social-collective
+and Family boundaries. These live tasks retain the unfinished migration scope.
+No additional actionable residual is introduced by this scaffold.
+
+## Verification result — 2026-09-05
+
+Registry/frontmatter integrity, nine directory categories, core documentation
+locations, and 26 relative links pass. All 52 pre-existing source and historical
+workplan files match their SHA-266 snapshot. The federation ledger verifies its
+pinned source: zero unowned or multiply owned concepts. git diff --check passes.
+See [project evidence](../../prj-canon-federation/docs/evidence/2026-09-05-commerce-layout.md).