🚧 Early alpha — building the foundation. See the roadmap →
Artifact roles and authority — synthesis (minimal model, scoped authority)
§1 Verdict
Section titled “§1 Verdict”Crosswalker’s root model is one governing meta-artifact, two domain-artifact families, and two separate planned administrative envelopes.
| Decision | Verdict |
|---|---|
| Schema Contract | Adopted: governing meta-artifact; answers what representations are valid |
| Knowledge Set | Adopted: extensional family, what is asserted; conceptual distinction settled, generalized schema deferred |
| MappingSet / MappingAssertion | Adopted: MappingSet is a Knowledge Set subtype; MappingAssertion is a member |
| Recipe / ImportRecipe | Adopted: intensional family, what should be done; ImportRecipe is the implemented subtype |
| Execution Record | Planned separately: historical receipt for what actually happened |
| Package Manifest | Planned separately: distribution and attestation envelope |
| Tier 1 as a root artifact | Rejected: Tier 1 is the canonical Crosswalker-managed representation/authority tier |
| Blueprint / lifecycle manifest umbrella | Rejected: no independent semantics beyond Recipes, bindings, executions, packages, and ordinary lifecycle workflow |
§2 Load-bearing principle
Section titled “§2 Load-bearing principle”Authority follows ontological role, not storage location, format, lifecycle phase, or UI model.
A Recipe is authoritative for intended behavior; a Knowledge Set for asserted knowledge; an Execution Record for verified run facts; a Package Manifest for a resolved release; a Schema Contract for conformance. Moving or serializing one does not transfer those authorities.
§3 Reconciliation
Section titled “§3 Reconciliation”| Prior commitment | Reconciliation |
|---|---|
| Ontology lifecycle management | Remains the product identity. Acquire, shape, connect, understand, share, and maintain are activities, not artifact classes. |
| Data morphology | Remains the operating model for shapes and operations; it does not create a “transformative artifact” family. |
| Schema as primitive | Clarified: Schema Contract governs validity; Tier 1 is the canonical managed representation, not the root noun. |
| Portable ImportRecipe fidelity | Strengthened: the Recipe specification outranks RecipeDocument, ImportMapping, drafts, bindings, and editor state. |
| Bases query architecture | Queries and reports are machine-actionable Recipe policy, bindings, or derivative renditions, not a new root family. |
§4 Roadmap consequences
Section titled “§4 Roadmap consequences”| Area | Consequence |
|---|---|
| v0.1.7 portability | Durable ImportRecipe storage/browser remains a Recipe lifecycle feature; it must not absorb MappingSets or execution history |
| Mapping authoring | First-class MappingSet identity, membership, provenance, and release semantics need an independent future contract |
| v0.1.8 audit | Execution Record and Package Manifest must be designed as separate envelopes, even if one manifest references execution receipts |
| Query/export | Generated Bases files, reports, TSV, JSON, and Markdown remain derivative renditions or serializations |
| Product naming | Do not introduce Blueprint, lifecycle manifest, or another umbrella noun without demonstrably new authority and consumers |
§5 Recommended build sequence
Section titled “§5 Recommended build sequence”- Lock source/run binding and stable identity/hash boundaries.
- Complete the ImportRecipe library and retained exact-source replay.
- Define the minimal MappingSet contract, canonical serialization, and UI.
- Define the Execution Record contract and generate one terminal record per run.
- Connect audit, git, and signing behavior through execution IDs.
- Define the Package Manifest and package inspection/verification UI.
- Prove the complete artifact chain at RC.
- After RC, add remote acquisition, version-transition workflows, and marketplace package lifecycle.
§6 Non-commitments
Section titled “§6 Non-commitments”- no generalized
KnowledgeSetJSON Schema in this decision; - no settled MappingSet storage or membership encoding;
- no normative Execution Record or Package Manifest fields yet;
- no requirement that every lifecycle behavior share one Recipe “god object”;
- no new public product label;
- no change to Tier 1, Recipe, or query machine schemas.
Related
Section titled “Related”- Artifact roles and authority — permanent concept model
- Vision — canonical product, operating-model, and machine-actionability statements
- Ontology lifecycle — product sequence and activities
- ETL and import — schema-as-primitive
- System architecture — Tier 1 and Tier 2 authority boundaries
- Portable ImportRecipe fidelity — canonical specification/editor boundary
- Terminology — existing Recipe,
RecipeDocument, and Tier definitions