Skip to content
🚧 Early alpha — building the foundation. See the roadmap →

Artifact roles and authority — synthesis (minimal model, scoped authority)

Created Updated

Crosswalker’s root model is one governing meta-artifact, two domain-artifact families, and two separate planned administrative envelopes.

DecisionVerdict
Schema ContractAdopted: governing meta-artifact; answers what representations are valid
Knowledge SetAdopted: extensional family, what is asserted; conceptual distinction settled, generalized schema deferred
MappingSet / MappingAssertionAdopted: MappingSet is a Knowledge Set subtype; MappingAssertion is a member
Recipe / ImportRecipeAdopted: intensional family, what should be done; ImportRecipe is the implemented subtype
Execution RecordPlanned separately: historical receipt for what actually happened
Package ManifestPlanned separately: distribution and attestation envelope
Tier 1 as a root artifactRejected: Tier 1 is the canonical Crosswalker-managed representation/authority tier
Blueprint / lifecycle manifest umbrellaRejected: no independent semantics beyond Recipes, bindings, executions, packages, and ordinary lifecycle workflow

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.

Prior commitmentReconciliation
Ontology lifecycle managementRemains the product identity. Acquire, shape, connect, understand, share, and maintain are activities, not artifact classes.
Data morphologyRemains the operating model for shapes and operations; it does not create a “transformative artifact” family.
Schema as primitiveClarified: Schema Contract governs validity; Tier 1 is the canonical managed representation, not the root noun.
Portable ImportRecipe fidelityStrengthened: the Recipe specification outranks RecipeDocument, ImportMapping, drafts, bindings, and editor state.
Bases query architectureQueries and reports are machine-actionable Recipe policy, bindings, or derivative renditions, not a new root family.
AreaConsequence
v0.1.7 portabilityDurable ImportRecipe storage/browser remains a Recipe lifecycle feature; it must not absorb MappingSets or execution history
Mapping authoringFirst-class MappingSet identity, membership, provenance, and release semantics need an independent future contract
v0.1.8 auditExecution Record and Package Manifest must be designed as separate envelopes, even if one manifest references execution receipts
Query/exportGenerated Bases files, reports, TSV, JSON, and Markdown remain derivative renditions or serializations
Product namingDo not introduce Blueprint, lifecycle manifest, or another umbrella noun without demonstrably new authority and consumers
  1. Lock source/run binding and stable identity/hash boundaries.
  2. Complete the ImportRecipe library and retained exact-source replay.
  3. Define the minimal MappingSet contract, canonical serialization, and UI.
  4. Define the Execution Record contract and generate one terminal record per run.
  5. Connect audit, git, and signing behavior through execution IDs.
  6. Define the Package Manifest and package inspection/verification UI.
  7. Prove the complete artifact chain at RC.
  8. After RC, add remote acquisition, version-transition workflows, and marketplace package lifecycle.
  • no generalized KnowledgeSet JSON 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.