Skip to content

Step 1b: the lift ADR and the lift map #169

New issue
New issue
Open
Open
Step 1b: the lift ADR and the lift map#169

Description

@Hafeok
Hafeok
opened on Nov 6, 2026

This issue is the session brief for the lift half of step 1 of the order of work (definition, chapter 7). The session posts its plan as a comment here and waits for approval.

Re-scoped 2026-11-12.

This issue only reads decision-driven-design, at tags and at main. Once both blockers below are met, an issue session can plan it.

Do not start until all of these hold:

If any of these does not hold, stop and say which one.

Read first

In this order:

  1. decision-driven-design applications/sdlc/product-cli/product-definition.md, at main: chapters 4, 5 and 7, and D1.1, D1.3, D1.16 to D1.21 (as amended by product-cli definition: amend D1.21 for the lift (rulings on product-cli#169) decision-driven-design#76) and D1.24.

  2. The accepted ADRs, ADR-0001 onward (ADR-0007 for repository discipline, ADR-0015 for the edition pin from Step 1a: pin sdlc: edition 1 (split from #169) #174).

  3. Emil's rulings comment on this issue, and the plan of 2026-11-06 (comment 6685760600) that it answers. Read the plan for its data only: the violation table, the Q3 counts and the Q4 term list.

  4. decision-driven-design at the tag v0.6.0:

    • applications/sdlc/what.md, in full, including §2.3 and the appendix "where the source went";
    • what/ontology.ttl and what/shapes.ttl;
    • core/decisions/DDD-dec-63.yaml, DDD-dec-64.yaml, DDD-dec-72.yaml, DDD-dec-91.yaml (which supersedes 72), DDD-dec-73.yaml and DDD-dec-113.yaml (the edition-1 rulings: the regime, the severities, the five shapes, E-7 and E-8).

  5. The lift input, read only:

    • mindovermachine-dev/product-cli at the tag rust-final (70395df): .product/products/product-cli/;
    • schema/ontology/product-framework.ttl, for the pf: terms.

    Read the Rust crates for behaviour only. Copy no line.

  6. AGENTS.md in this repository.

Plan first

Post a plan as a comment on this issue and wait for approval. The plan names:

  • each file;
  • each ADR number;
  • the shape of the lift map, including its authored section;
  • the derivation rules, and the list of authored rows you will propose;
  • the wire-name rule you will propose;
  • the tests.

Do not write files before approval.

Deliverables (one PR in product-cli)

1. ADR (the next free number): the lift (D1.4, D1.21, ADR-0009).

  • The frozen input:

    • repository mindovermachine-dev/product-cli at the tag rust-final (70395df);
    • command product domain export --product product-cli;
    • RDFC-1.0 graph hash sha256:ad855b900abd76bdc8a26d91ce995e267856dad8c47d15e1ee509f41c5d07e06, with 1,412 triples.

    Bytes are not the pin: Rust's Turtle is not byte-stable across builds.

  • The mapping of old Framework sections to what.md sections, once, taken from what.md's appendix.

  • The term rules. Every pf: class and predicate in the input is either mapped to an sdlc: term or dropped by name with a reason. The How kinds are dropped: ReificationRule, Cio, style and tokens, versionedAs, targetsPlatform. inContext, ownsDomain, ownsSystem, systemOf, journeyOf and boundedBy become sdlc:within (P-2).

  • The element rules:

    • IRI subjects that are vocabulary are not minted (Q3):
      • the 12 pf:Aio map to base-set individuals, each as a reviewed row;
      • the 6 pf:WcagCriterion map to their W3C IRIs;
      • pf:Cio, pf:ReificationRule and pf:DesignSystem subjects are dropped as How or catalogue (DDD-dec-57);
    • every other IRI subject gets one minted P/what/<ULID>, keyed in the map by its old IRI;
    • the 32 blank nodes become elements (P-3), each keyed in the map by (owning subject IRI, predicate, the node's own description, sorted). That key was checked unique over all 32 at the frozen graph hash, and the ADR states this, so the map needs no blank-node labels:
      • the 15 pf:hasAttribute nodes become sdlc:Field elements: attrName becomes rdfs:label, and attrType becomes sdlc:fieldType;
      • the 7 pf:offers and the 10 pf:surfaces nodes, all on wireframe steps, become sdlc:Interaction elements within their UI step. They keep command or projection, and typedAs (what.md §3.2.1);
    • the product IRI P is https://decision-driven-design.dk/products/product-cli (Q2).

  • Derived and authored facts (Q1).

    • Where the input determines a fact that edition 1 requires, the ADR states a derivation rule and the lift applies it. An example is an element's sdlc:within that follows from its flow or owner.
    • Where the input doesn't determine it, the fact is an authored row in the map, adopted in review with its reference, exactly like wire names. The 2026-11-06 plan lists the cases:
      • the domain or domains, and the systems' domain references;
      • the two triggers that appear in two systems' flows;
      • the missing labels;
      • the flow entry pages, and the two flows with no step;
      • the events behind each pf:projects edge;
      • the quality-demand statements;
      • rel-session-inphase-phase.
    • Re-run the violation table against the lifted graph: every row must be covered by a rule or an authored row.

  • The pf: What terms without an sdlc: counterpart (Q4) are mapped or dropped as the 2026-11-06 plan proposes. The exception is pf:targetsPlatform, which follows product-cli definition: amend D1.21 for the lift (rulings on product-cli#169) decision-driven-design#76's ruling.

  • The wire-name rule. The input carries none. State the rule that proposes them for every kind that requires one (what.md §6, R-1, R-2). Review adopts each, and the adopted name is stored in the map with a reference to the review that adopted it. Lifting again therefore reproduces the golden bytes, wire names included.

  • The two fixtures:

2. The lift map, lift/map-1.json, committed and never regenerated:

  • the term table;
  • the vocabulary rows (Q3);
  • one row per input element, by the keys above: key, new IRI (the minted ULID, stored rather than minted on each run), label, and wire name with its adoption reference;
  • the authored rows: subject, predicate, object, reason, and adoption reference;
  • the drop list.

ULIDs are minted once, here, and stored. The lift reads them from the map and never mints. The map is input to step 3 and is not used by the product.

3. Tests (C#, observing bytes, ADR-0006):

  • the lift map covers the frozen input: every subject and every pf: term is mapped or dropped, and nothing in the map is absent from the input;
  • every minted IRI matches the identity shape's pattern;
  • wire names are unique per kind, and within each owner for fields;
  • every authored row and every vocabulary row has an adoption reference.

These tests read the input by its frozen hash. A changed input fails them.

Stubs: none expected. List any you need in the PR.

Rules

  • Commits:
    • signed, as the agent identity, with no model identifier in any commit or record;
    • Refs #N and a DCO sign-off;
    • a traceability record for the session.
  • No suppression of any analyzer or rule.
  • Package versions come from nuget.org, never from memory. Each new package needs an ADR with an Adr= entry in the register.
  • Nothing is written to decision-driven-design, Varve or Writ. A gap found there is an issue in that repository, linked from the PR.
  • Nothing under .github/ or eng/gates/ changes.
  • ADRs are files under the interim rule (A7) until Milestone: First slice — the C# file projector and the layer rule Hafeok/writ#7 exists.

Done when

  • The PR is green.
  • The lift ADR is accepted.
  • The map is reviewed, and its wire names, vocabulary rows and authored rows are adopted.
  • The release descriptor (the next free preview) names the lift input hash and the map.

Reconciliation

If another session lands first:

  • merge main;
  • re-run the tests;
  • if that session touched the edition pin or the map, stop and ask.

Generated by Claude Code

Activity

  1. Hafeok commented on Nov 6, 2026

    @Hafeok
    Hafeok
    on Nov 6, 2026 – with Claude
    CollaboratorAuthor

    Plan for step 1: edition 1 pin, the lift ADR and the lift map

    I have written no files yet. I am waiting for approval, and for rulings on Q1 to Q5 at the end. Q1 blocks the map.

    Preconditions: all hold (checked 2026-11-06)

    Precondition Evidence
    v0.6.0 cut and verified tag object bb47a72 on 1ab1de0. GitHub reports verified: true (valid). The descriptor's edition hash is sha256:a2006d9d…2f29. I recomputed it from the tagged ontology.ttl then shapes.ttl and got the same value.
    mindovermachine-dev/decision-driven-design#52 merged merged 2026-11-03
    rust-final at 70395df tag object d0cf1f1, commit 70395dfe…
    Rust tree off main (D1.24) main holds no Rust files
    slice 0 (D1.25) main is at 4ce90e9

    The lift input reproduces. I parsed .product/products/product-cli/product-cli.ttl at rust-final with pyoxigraph, in the scratchpad only, and computed its RDFC-1.0 hash. It is sha256:ad855b90…7e06: 1,412 triples, 289 subjects, 32 blank nodes. That matches the frozen input.

    I also checked the blank-node key (owner IRI, predicate, sorted description):

    • it is unique over all 32 nodes;
    • every blank node has exactly one owner;
    • none is nested.

    Deliverable 0: decision-driven-design, one PR, first

    • The file: only applications/sdlc/product-cli/product-definition.md.
    • The edits: exactly the edits the brief lists. Every line is still at the number the brief gives (174, 194, 282, 380, 394, 443, 457, and the table), so none has moved.
    • The commit: one signed commit with Refs #49, Refs #50, Basis: DDD-dec-113; DDD-dec-73; DDD-dec-72 and the DCO.
    • The check: python3 scripts/ci.py passes before I push.

    If Q1 is ruled (a), this PR gains a second edit. See Q1.

    Deliverables 1 to 4: product-cli, one PR, after deliverable 0 lands

    ADRs. Both are written as Proposed. A session never writes accepted-by.

    • docs/decisions/ADR-0014-sdlc-edition-1-pin.md. It covers:

      • the pin: owl:versionIRI …/sdlc/1, the tag v0.6.0 (bb47a72 on 1ab1de0), and the edition hash per DDD-dec-72 as carried by DDD-dec-91;
      • the regime of DDD-dec-113 E-1: the data graph is what ∪ ontology, SHACL Core class semantics with SHACL-SPARQL, no entailment, and the ontology is never hashed;
      • the severity mapping: a violation is refused at write (W1, W5), and a warning is a finding (W3, W4);
      • the embedding (A5): byte for byte, and the build fails on a hash mismatch;
      • alternatives refused: a runtime fetch, and an edited vendored copy;
      • consequences: edition 2 is a new ADR that shows edition-1 exports still import, validate and diff (constraint 8).

    • docs/decisions/ADR-0015-the-lift.md (D1.4, D1.21). It covers everything in deliverable 2:

      • the frozen input;
      • the old-section-to-what.md table, taken once from the appendix;
      • the term, element and wire-name rules;
      • P;
      • the two fixtures.

      It also amends ADR-0009 D1 and D2, naming them (ADR-0001 D3). ADR-0009 put the outputs at tools/migrate-pf and fixtures/self-hosted/, as a separate term map and IRI map. The single map is now lift/map-1.json. The lift tool itself arrives at step 3.

    The edition, embedded (layer 0):

    • src/ProductCli.Vocabulary/Edition/sdlc-1/ontology.ttl and shapes.ttl, byte copies from v0.6.0, with a SOURCE.md recording the tag, commit and sha256s.
    • .gitattributes marks them -text.
    • They are EmbeddedResource items in ProductCli.Vocabulary.csproj.
    • eng/Edition.targets:
      • it hashes the two files in order before compile, with an inline RoslynCodeTaskFactory task, so no package is added;
      • it fails the build with PCLI0006 when the result differs from the pin (PCLI0001 to PCLI0005 are taken);
      • the pin is held once, as properties SdlcEditionVersionIri and SdlcEditionHash.
    • No public API in step 1. The accessor arrives with the shape engine (step 4), so the baselines don't change.

    The lift input and the map:

    • lift/input/product-cli.ttl, the committed file's bytes at rust-final, -text. The pin is the graph hash, not the bytes: any isomorphic export passes. lift/input/SOURCE.md records the blob and commit.
    • lift/map-1.json, written once and never regenerated. Its shape: 
      {
  "format": "product-cli/lift-map/1",
  "input":   { "repository", "tag": "rust-final", "commit", "command", "graphHash", "triples": 1412, "subjects": 289, "blankNodes": 32 },
  "edition": { "versionIRI", "hash" },
  "product": "<P>",                          // Q2
  "terms":   [ { "pf": "<iri>", "sdlc": "<iri>", "rule": "rename | within (P-2) | value-map | object-rewrite", "values"?: {…}, "reason" } ],
  "drops":   [ { "pf": "<iri>", "reason": "…" } ],     // classes and predicates dropped by name
  "elements": [                               // one row per input element, sorted by key
    { "key": { "iri": "<old IRI>" } | { "owner": "<old IRI>", "predicate": "<pf iri>", "description": [["<p>","<o as N-Triples>"], …] },
      "kind": "sdlc:…", "iri": "P/what/<ULID>", "label": "…",
      "wireName"?: { "name": "…", "adoptedBy": "<review URL>" } } ],
  "vocabulary": [ { "key": { "iri": "<old IRI>" }, "sdlc": "<individual or W3C IRI>", "reason" } ],   // Q3
  "droppedSubjects": [ { "key": { "iri": "<old IRI>" }, "reason" } ],
  "authored": [ { "subject", "predicate", "object", "reason", "adoptedBy" } ]                        // Q1
}
      • Formatting: 2-space indent, UTF-8, LF, final newline, and every array sorted.
      • ULIDs: minted once, in this session, with decision-driven-design's what/mint.py at v0.6.0, run in the scratchpad, since no Python goes in the tree. The record states this. The lift reads the ULIDs from the map and never mints.
      • Adoption: the first map commit carries proposed wire names, with adoptedBy absent. After your review, a second commit fills each adoptedBy with the review comment's URL.

    The wire-name rule. A wire name is the lifted rdfs:label, lowercased, with each run of characters outside [a-z0-9] replaced by -, and trimmed. Examples: Add Bounded Context becomes add-bounded-context, and Initialize Agent Context becomes initialize-agent-context.

    • Which kinds need one: the kinds WireNameShape and FieldWireNameShape require, per R-1 and R-2. In the input that is:
      • 15 commands;
      • 16 events;
      • 33 invariants. WireNameShape targets every invariant at sh:Violation, not only those in rejections.
    • Fields: the input has no payload, claim or view fields. The 15 attributes are within entities, so none needs a wire name.
    • Invariants need labels first. They have none in the input, so the rule runs on the label adopted for each (Q1).
    • Checked on a dry run: no collisions per kind, and every name is a valid dpp/1 token. A collision would fail the map and be resolved in review.

    The tests. All are C# and observe bytes (ADR-0006).

    • tests/ProductCli.Vocabulary.Tests/EditionTests.cs:
      • the resources embedded in the built ProductCli.Vocabulary.dll equal the Edition/ files byte for byte;
      • sha256 over ontology.ttl then shapes.ttl equals the pin;
      • ontology.ttl declares owl:versionIRI <…/sdlc/1>, parsed with Varve.Turtle.
    • BuildPolicyTests, a new planted case: a probe whose shapes.ttl has one byte changed fails with PCLI0006.
    • tests/Lift.Tests/: a new test project in ProductCli.slnx, using Varve.Rdf and Varve.Turtle, which are already admitted with Scope="tests/". So: no new package and no stubs.
      • LiftInputTests: the RDFC-1.0 hash equals the pin, with 1,412 triples, 289 subjects and 32 blank nodes. Every other lift test first loads the input through this check, so a changed input fails them all.
      • LiftMapCoverageTests:
        • each IRI subject is in exactly one of elements, vocabulary or droppedSubjects;
        • each blank node's computed key matches exactly one element row;
        • each pf: class and predicate is in terms or drops;
        • nothing in the map is absent from the input;
        • keys are unique.
      • LiftMapIdentityTests: every minted IRI matches ElementIdentityShape's sh:pattern, read from the embedded shapes.ttl rather than retyped, and starts with P. IRIs are unique.
      • WireNameTests:
        • every command, event and invariant row has exactly one wire name, which matches WireNameShape's token pattern and is unique per kind;
        • field wire names are unique within their owner;
        • every wire name, and every authored row, has an adoptedBy. This fails until review adopts them, which is what "done" requires.

    Also in this PR:

    • AGENTS.md: the lift/ directory, the edition embedding and PCLI0006.
    • releases/v0.8.0-preview.3.yaml, naming the edition pin and the lift input hash.
    • docs/traceability/2026-11-06-issue-169-edition-1-and-lift.md.

    Commits. Each is signed as the agent, with Refs #169 and the DCO:

    1. ADR-0014;
    2. the edition embedding, PCLI0006 and their tests;
    3. ADR-0015;
    4. the input, the map and the lift tests;
    5. after review, the adoption references;
    6. the descriptor, AGENTS.md and the record.

    Findings that need a ruling

    Q1, blocking: the golden fixture cannot be violation-free from term and element rules alone.

    I lifted the input naively in the scratchpad, applying only the rules in the brief plus the obvious renames. I ran edition 1's shapes over it under the E-1 regime (pyshacl, what ∪ ontology, no inference). The result is 167 violations from 8 shapes:

    Violations Shape Cause in the input
    83 every element is within one element no ownership edge for 48 relations, 15 triggers, 7 UI steps, 5 views, 3 invariants, 3 mappings and 2 contexts of use
    53 an element has an rdfs:label 33 invariants, 3 context mappings and 17 interactions are unlabelled
    9 a bounded context lies within a domain the input has no domain: pf:ownsDomain points at bounded contexts
    3 a system references its domains the input has no referencesDomain
    8 a view projects only events pf:projects is View → Entity, while sdlc:projects is View → Event
    6 a flow has one entry page none is declared, and 2 flows contain no step
    4 a quality demand has a statement only pf:bound exists
    1 a relation connects two entities rel-session-inphase-phase points to a value object

    Some of these are derivable, for example a step within the system of its flow or root. Others need a choice:

    • triggers: t-render and t-open-view sit in flows of two systems;
    • one domain or nine;
    • labels;
    • entry pages.

    D1.21 makes only wire names authored, so the map has nowhere to record these choices. I propose (a): the map gains the authored section above. Each row is adopted in review with its reference, the same mechanism as wire names. D1.21 is amended to allow it, in deliverable 0 as one added clause. Lifting again then still reproduces the golden bytes.

    The alternative is (b): a separate definition PR before the product-cli PR. Deliverable 0 says "change nothing else", so I need your ruling on which.

    Q2: the product IRI P. The old IRI is https://productframework.org/product/product-cli, and acme uses https://acme.example/products/shop. Options:

    • https://decision-driven-design.dk/products/product-cli;
    • a domain mindovermachine-dev controls;
    • another you name.

    I won't choose one.

    Q3: IRI subjects that are not elements under sdlc:. The brief says each IRI subject gets a ULID, but what.md §3.2.2 and §3.2.3 make some of these vocabulary:

    • 12 pf:Aio: I propose each maps to a base-set individual, for example aio-nav-tabs to sdlc:aioNavigate. Each choice is a reviewed row.
    • 6 pf:WcagCriterion: each maps to its W3C IRI, for example #contrast-minimum. Nothing is re-minted under P.
    • Dropped as How or catalogue (Q-3, DDD-dec-57): 11 Cio, 12 ReificationRule and 2 DesignSystem. The self-hosted What then declares no design-system target, because a DeclaredTarget needs an edition reference the input lacks.

    That leaves 213 minted IRI elements and 32 blank-node elements, plus P.

    Q4: pf: What terms with no sdlc: counterpart. ADR-0009 D4, as amended, fails the lift on an unmapped What term. The brief rules only the How drops. I will put each of these in the map with a proposed reason, for you to confirm or send to decision-driven-design as an edition question:

    Term Proposal
    pf:projects dropped; its meaning changed (see Q1)
    pf:displays, pf:triggers dropped; the step's interactions carry them
    pf:contains to sdlc:inFlow for steps; dropped for commands, events and views
    pf:appliesTo, pf:identity, pf:means, pf:contextValue, pf:constrains dropped; constrains points at two IRIs that are not subjects
    pf:level, pf:verification, pf:satisfied dropped: W3C's data, and a stored verdict (DDD-dec-52)
    pf:mappingKind dropped: E-8 makes strategic pattern kinds How
    pf:mustSatisfy on an AIO moved onto the interactions typed by it
    pf:targetsPlatform dropped, as the brief says, although sdlc:targetsContext is documented as its generalisation

    Q5: the behaviour fixture's test. It needs a SHACL engine, Varve.Shacl and Varve.Shacl.Sparql, which is a new package and so an ADR. I read it as step 3, where the fixtures are imported. In step 1, ADR-0015 states the fixture and its zero-violation, zero-warning assertion, and acme-shop-5.ttl is not vendored yet. Is that right?

    Generated by Claude Code

  2. Hafeok commented on Nov 9, 2026

    @Hafeok
    Hafeok
    on Nov 9, 2026 – with Claude
    CollaboratorAuthor

    Numbering update to the plan above. #171 takes ADR-0014 and v0.8.0-preview.3, so this step shifts:

    • the edition pin becomes ADR-0015;
    • the lift becomes ADR-0016;
    • the release descriptor becomes v0.8.0-preview.4.

    When I write the files, I will take whichever numbers are free at that point. I will rebase onto #171 and record the reconciliation in the session record (ADR-0007 D5).

    Nothing else changes in the plan, and Q1 to Q5 are still open.

    Generated by Claude Code

  3. Hafeok
    added 5 commits that reference this issue on Nov 9, 2026

    product-cli definition: edition 1 shipped in v0.6.0; D1.19 ruled, M-1…

    577ef5f

    product-cli definition: edition 1 shipped in v0.6.0; D1.19 ruled, M-1…

    e037d8e

    sdlc.md §19: O-8 (accepting the realisation plan) and O-9 (product-cl…

    b79d326

    sdlc.md §19: O-8 (accepting the realisation plan) and O-9 (product-cl…

    80e9088

    docs(traceability): #169 record, Round 5 and the #66 rebase onto e037d8e

    ca588f5
  4. Hafeok
    added
    claudeStart a Claude Code action session (Emil only); see AGENTS.md
    on Nov 11, 2026

  5. Hafeok commented on Nov 11, 2026

    @Hafeok
    Hafeok
    on Nov 11, 2026 – with Claude
    CollaboratorAuthor

    No plan posted: this issue needs a definition change in decision-driven-design first, so a normal session must do it.

    The issue-session prompt (version 1) and AGENTS.md both rule this out for an issue session. I changed no file, made no commit and pushed nothing.

    The start

    The start checks passed: the claude label was applied by hand by Hafeok on 2026-11-11, it is still on the issue, and no plan comment with Answers: label existed.

    What holds

    What blocks the lift map

    D1.21 has not changed since deliverable 0, and under it the map cannot be written so that the golden fixture "carries no violation under its edition". D1.21 lets the map hold terms, ULIDs and wire names only. I re-checked the input against edition 1's shapes, and it needs facts that none of those can carry:

    Edition 1 requires, as a violation The frozen input
    a bounded context is within a domain (BoundedContextShape) has no domain at all: all 9 pf:ownsDomain edges point from the product to a bounded context
    a view projects only events (ViewShape) all 8 pf:projects edges point from a read model to an entity
    every element is within one element, and is labelled (KindNeedsContainerShape) no ownership edge on 48 relations, 15 triggers, 7 wireframe steps, 5 read models, 3 context mappings and 3 invariants; no rdfs:label on 33 invariants and 3 context mappings

    This is Q1 of the plan of 2026-11-06 (comment 6685760600), and it is still unruled. Both of its options change D1.21. Q3 does too: D1.21 gives every IRI subject a minted ULID, but 12 Aio and 6 WcagCriterion subjects are vocabulary under what.md, and 25 more are How. Q2 (the product IRI P), Q4 and Q5 are also open, but they can be answered on this issue.

    What a normal session needs

    1. Your rulings on Q1 and Q3.
    2. A pull request in decision-driven-design that amends D1.21 accordingly, landed.
    3. Then step 1's pull request here, citing that commit beside e037d8e.

    One part does not depend on any of this

    The edition half needs no definition change and no other repository: the pin ADR, the two embedded files, the build-time hash check and their tests. If you split it into its own issue, an issue session can plan it. Numbering has moved since the note of 2026-11-09: ADR-0015 is the next free ADR, and v0.8.0-preview.3 is taken, so the next descriptor is v0.8.0-preview.4.

    Generated by Claude Code

  6. Hafeok
    changed the title [-]Step 1: pin sdlc: edition 1, the lift ADR and the lift map[/-] [+]Step 1b: the lift ADR and the lift map[/+] on Nov 12, 2026
  7. Hafeok
    removed
    claudeStart a Claude Code action session (Emil only); see AGENTS.md
    on Nov 12, 2026

  8. Hafeok commented on Nov 12, 2026

    @Hafeok
    Hafeok
    on Nov 12, 2026
    CollaboratorAuthor

    Rulings on Q1–Q5 of the plan in comment 6685760600:

    Q1: (a), refined. The lift ADR states derivation rules for every fact the input determines (e.g. sdlc:within from an element's flow or owner). Only facts the input does not determine become rows in the map's authored section, each adopted in review with its reference, like wire names. D1.21 is amended for this in mindovermachine-dev/decision-driven-design#76.
    Q2: P = https://decision-driven-design.dk/products/product-cli
    Q3: as proposed. Aio → base-set individuals (reviewed rows), WcagCriterion → W3C IRIs, Cio/ReificationRule/DesignSystem dropped.
    Q4: as proposed, except pf:targetsPlatform: ruled in mindovermachine-dev/decision-driven-design#76, not dropped here.
    Q5: as proposed. SHACL engine and its ADR belong to step 3; step 1 only states the fixture's zero-findings assertion.

    The edition pin moves to #174. This issue is now the lift only.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    Priority

    None yet

    Effort

    None yet

    Progress

    None yet

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions