diff --git a/SCOPE.md b/SCOPE.md index b5ef6ad..5b61fc3 100644 --- a/SCOPE.md +++ b/SCOPE.md @@ -22,9 +22,16 @@ later via demand signal; their adoption is not a gate of this project. ## In scope - Concept-ownership boundary across Custodian canon, InfoTechCanon, CommerceCanon. -- Resolution of the six ownership collisions listed in `ADR-006`. +- Resolution of the ownership collisions listed in `ADR-006` (R1–R7, accepted + 2026-08-17). - The `identity-canon` → `commerce-canon` rename and all fleet references to it. - Landing `itc-ident` in InfoTechCanon with imports, not redefinitions. +- Landing `itc-evid`, the evidence model, per R3/R5/R7 — including moving + `Evidence` out of `itc-gov`, which becomes an importer. +- Extending `itc-org` with `Community` and `Household` under `CollectiveActor` + per R6. (Promoted from residual to scope by the R6 resolution.) +- Seeding `Family` as its own concept area per R6 — recording the concept, + its privacy sensitivity, and open modelling questions only. - Bringing CommerceCanon to `InfoTechCanonRepositoryLayoutStandard` structure. - Distributing the research corpus as provenance. - Cross-canon interface cards. @@ -37,9 +44,10 @@ later via demand signal; their adoption is not a gate of this project. - Building CommerceCanon's service surface (CLI/JSON/API). InfoTechCanon has one; whether CommerceCanon needs one is a later, evidence-driven decision. - Moving the Federated Organization Standard out of Custodian canon. -- Extending `itc-org` with social collectives (`Community`, `Family Or - Household`) beyond recording the recommendation — that is an InfoTechCanon - workplan if adopted. +- Authoring the `Family` concept area beyond a seed. Family carries kinship, + guardianship, dependency, care, and legal/biological/social parenthood + structure that changes over time; building it out speculatively is the + failure mode R6 exists to avoid. It grows on demand signal. - Consumer adoption of either canon. - Retiring or deleting any repository. diff --git a/WORK-RECORDS.md b/WORK-RECORDS.md new file mode 100644 index 0000000..d5bd635 --- /dev/null +++ b/WORK-RECORDS.md @@ -0,0 +1,21 @@ +# Work Records — prj-canon-federation + +> Generated by `statehub fix-consistency` (CUST-WP-0061-T04, work-record +> stage 3). Do not edit by hand — edit the source file/block listed for +> each record and re-run fix-consistency to refresh this index. Archived +> workplans are omitted; closed decisions/intakes/engagements stay listed +> so recently-resolved work is still visible. [auto] + +| Kind | ID | Status | Lane | Source | +| --- | --- | --- | --- | --- | +| workplan | CFED-WP-0001 | ready | — | workplans/CFED-WP-0001-foundation.md | +| task | CFED-WP-0001-T01 | todo | — | workplans/CFED-WP-0001-foundation.md | +| task | CFED-WP-0001-T02 | wait | — | workplans/CFED-WP-0001-foundation.md | +| task | CFED-WP-0001-T03 | wait | — | workplans/CFED-WP-0001-foundation.md | +| task | CFED-WP-0001-T04 | wait | — | workplans/CFED-WP-0001-foundation.md | +| task | CFED-WP-0001-T05 | wait | — | workplans/CFED-WP-0001-foundation.md | +| task | CFED-WP-0001-T06 | wait | — | workplans/CFED-WP-0001-foundation.md | +| task | CFED-WP-0001-T07 | wait | — | workplans/CFED-WP-0001-foundation.md | +| task | CFED-WP-0001-T08 | wait | — | workplans/CFED-WP-0001-foundation.md | +| task | CFED-WP-0001-T09 | wait | — | workplans/CFED-WP-0001-foundation.md | +| task | CFED-WP-0001-T10 | wait | — | workplans/CFED-WP-0001-foundation.md | diff --git a/workplans/CFED-WP-0001-foundation.md b/workplans/CFED-WP-0001-foundation.md index bd545f7..3233543 100644 --- a/workplans/CFED-WP-0001-foundation.md +++ b/workplans/CFED-WP-0001-foundation.md @@ -9,6 +9,7 @@ owner: codex topic_slug: canon-federation created: "2026-08-16" updated: "2026-08-16" +state_hub_workstream_id: "7a96da54-050d-4210-96f9-0bb411aaaec8" --- # Canon federation foundation: boundary, rename, and model placement @@ -26,8 +27,9 @@ Governed by `ADR-006` in the Custodian canon. No content moves before T01. ```task id: CFED-WP-0001-T01 -status: todo +status: done priority: high +state_hub_task_id: "39a2c720-b923-4c5b-aa0c-2991e54a6e3b" ``` Resolve the six open ownership questions in `ADR-006` and move it to `accepted`. @@ -50,18 +52,52 @@ This is a human review gate — every later task depends on it. Record each resolution with rationale in `ADR-006`, then set its status to `accepted`. +**Result (2026-08-17):** `ADR-006` accepted. Seven resolutions recorded — the +six above plus R7, raised by the R3 reframing. + +- **R1** `Scope` → `itc-ident`. No head-on collision existed: `itc-access` owns + the narrower `ResourceScope`, not a general `Scope`. +- **R2** `Assurance Level` → `itc-ident`, distinct from `itc-gov` + `AssuranceCase`/`AssuranceConclusion`. A shared English word, not a shared + concept. +- **R3** `Evidence` and `Evidence Source` are a **general pair**, not rival + definitions: the source is an addressable information container (URI- + identifiable document or artifact); the evidence is a distinct assertion drawn + from it. Invoice case: the signed PDF is the source; amount, issuer, and due + date are separate evidence items. Neither belongs to commerce. `itc-gov` no + longer owns `Evidence`. +- **R4** `Relationship Tuple` → `itc-access`, where it is already modelled + (`:549`). No decision needed; a duplicate avoided. +- **R5** `Adjudication Outcome` follows R3 — general, not commerce-owned, and + structurally *Evidence* sourced from a judgment document. `assurance_tier` + splits: general strength dimension in the evidence model, `Counterparty + Assurance Gradient` stays commerce as its named four-tier application. +- **R6** `Community` and `Household` extend `itc-org` under `CollectiveActor`; + `Family` is rejected as a collective actor and gets its own seeded concept + area. identity-canon's combined "Family Or Household" entry is split. +- **R7** the evidence pair lives in a dedicated model, **`itc-evid`**, imported + by `itc-gov`, `itc-ident`, and `commerce-canon`. + +Scope consequences: T11–T13 added below. `itc-org` extension promoted from +residual to scope; `Family` seeded but explicitly not authored. + ## Build the concept-ownership ledger ```task id: CFED-WP-0001-T02 -status: wait +status: todo priority: high +state_hub_task_id: "0ca7878c-f925-44f3-bf00-51b91fba0b3e" ``` Produce a machine-readable ledger under `ledger/` mapping every concept in `identity-canon/canon/CanonicalGlossary.md` (as of project start) to exactly one owning canon and model, with disposition: `import` (defined upstream, referenced -here), `own` (moves and stays owned), or `retire` (dropped, with rationale). +here), `own` (moves and stays owned), `split` (one entry becomes two, as with +"Family Or Household" under R6), or `retire` (dropped, with rationale). + +Owning models are `itc-ident`, `itc-evid`, `itc-org`, `itc-access`, `itc-gov`, +the `Family` area, and `commerce-canon`, per `ADR-006` decision 4 and R1–R7. Include a validation pass that reports concepts with zero owners and concepts with two. Zero of both is gate **G2**. @@ -75,6 +111,7 @@ rather than from prose. id: CFED-WP-0001-T03 status: wait priority: high +state_hub_task_id: "45cd377e-d6f1-4708-8fb4-a822b2930aed" ``` Rename the repository in place, preserving git history: @@ -98,6 +135,7 @@ slug-rename rule. id: CFED-WP-0001-T04 status: wait priority: medium +state_hub_task_id: "743a2da9-56b3-4c3a-ba89-94a3525ce3b7" ``` Bring the renamed repository up to `InfoTechCanonRepositoryLayoutStandard`: @@ -120,6 +158,7 @@ a later evidence-driven decision (`SCOPE.md`, out of scope). id: CFED-WP-0001-T05 status: wait priority: high +state_hub_task_id: "986a0ac6-12c2-4bae-a849-c23f1da10325" ``` Create `info-tech-canon/infospace/models/identity/InfoTechCanonIdentityModel.md` @@ -144,6 +183,7 @@ or `itc-access`. id: CFED-WP-0001-T06 status: wait priority: high +state_hub_task_id: "0a29bb3e-6460-4c4a-ba19-bcd2c38cd344" ``` Create the counterparty/commercial model in `commerce-canon` from the ledger's @@ -167,6 +207,7 @@ and P15 ("Model Commercial Binding Explicitly"), which are commerce-side. id: CFED-WP-0001-T07 status: wait priority: medium +state_hub_task_id: "776905c6-26a9-4754-b289-d9dd4d328fb5" ``` Route `research/` (8 subject areas + `CorpusIndex.md`), `terminology/` @@ -183,6 +224,7 @@ Record the disposition so gate **G6** is checkable. id: CFED-WP-0001-T08 status: wait priority: medium +state_hub_task_id: "3eee0510-cfa0-4571-a599-8654c3f01aa0" ``` Each canon publishes a Canon Interface Card naming what it imports from and @@ -199,6 +241,7 @@ Include Custodian canon in the map — it governs both domain canons and holds id: CFED-WP-0001-T09 status: wait priority: medium +state_hub_task_id: "5d3e744e-b390-41e1-b7ca-caa4cf60664e" ``` Find and fix every live reference to `identity-canon` across the fleet: repo @@ -208,20 +251,90 @@ registries, and `reuse-surface` entries. Deliberate historical provenance Gate **G8** is a clean sweep. +## Land the evidence model in InfoTechCanon + +```task +id: CFED-WP-0001-T11 +status: wait +priority: high +``` + +Create `info-tech-canon/infospace/models/evidence/` (`itc-evid`) per R3, R5, R7, +owning `Evidence`, `Evidence Source`, `Adjudication Outcome`, and the general +evidence-strength dimension. + +Model the pair explicitly: `Evidence Source` as an addressable information +container (URI-identifiable), `Evidence` as a distinct assertion drawn from a +source, with a containment/derivation relation between them. Both may carry +commentary. Which evidence is captured from a source depends on the interest +being served — the model must not presume a fixed extraction. + +Use the invoice case as the worked example, including the electronic-invoicing +pattern of a signed PDF carrying an XML embedding, which is evidence +pre-extracted and bound to its source so the extraction is tamper-evident. + +Then rework `itc-gov`: remove `Evidence` from its owned concepts, add the import, +and re-express the Policy-Control-Evidence chain pattern (`:1391`) over imported +concepts. `AssuranceCase`, `AssuranceConclusion`, and `Audit` stay with `itc-gov`. + +Register in `canon.yaml` and the kernel map. Verification: exactly one model +defines `Evidence`. + +## Extend itc-org with social collectives + +```task +id: CFED-WP-0001-T12 +status: wait +priority: medium +``` + +Add `Community` and `Household` to `InfoTechCanonOrganizationModel` under the +existing `CollectiveActor` (`:363`), per R6. + +This widens `itc-org` from enterprise structures into social ones — a real and +deliberate scope broadening, to be stated in the model rather than slipped in. +P4 ("Model Collective Actors Without Collapsing Them") governs: `Community`, +`Household`, `Team`, and `Group` remain distinct. + +## Seed the Family concept area + +```task +id: CFED-WP-0001-T13 +status: wait +priority: medium +``` + +Split identity-canon's combined "Family Or Household" entry. `Household` goes to +`itc-org` (T12); `Family` becomes its own concept area — **seeded, not +authored**. + +Record only: the concept, its distinguishing structure (kinship, guardianship, +dependency, care, and legal, biological, and social parenthood, changing over +time and open to interpretation), the privacy sensitivity already flagged in +identity-canon ("may have legal implications outside the canon's scope"), and the +open modelling questions. + +Do not build it out. Modelling family as one more collective actor is the +specific mistake most family-oriented software makes, and the reason such +software generally models families badly; authoring it speculatively here would +repeat that mistake at canon level. It grows on demand signal like any other +canon content. + ## Record open residuals ```task id: CFED-WP-0001-T10 status: wait priority: low +state_hub_task_id: "f89a08fe-c6ba-4f81-a063-6f49727eae2d" ``` Before this workplan is set to `finished`, every actionable leftover becomes a live work record outside this repository, per `work-record-types_v0.1.md` § Residuals. Expected residuals: -- `itc-org` extension for social collectives (`Community`, `Family Or - Household`), if T01 confirms the recommendation — an InfoTechCanon workplan; +- build-out of the `Family` concept area beyond the T13 seed — demand-signal + driven, and deliberately out of scope here; - CommerceCanon service-surface decision, if demand appears; - consumer adoption by `fin-hub`, `target-revenue`, `adaptive-pricing`, `qonto-assistant` — demand-signal driven, explicitly not a gate here.