smd-engine 0.3.7__py3-none-any.whl

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (82) hide show
  1. smd_engine/__init__.py +9 -0
  2. smd_engine/apply.py +247 -0
  3. smd_engine/assets/data-model.md +266 -0
  4. smd_engine/assets/lenses/README.md +90 -0
  5. smd_engine/assets/lenses/design-chain.md +116 -0
  6. smd_engine/assets/lenses/fliamer-diamond.md +113 -0
  7. smd_engine/assets/lenses/khaprov-levels.md +104 -0
  8. smd_engine/assets/lenses/khaprov-ontology.md +110 -0
  9. smd_engine/assets/lenses/scamper-check.md +83 -0
  10. smd_engine/assets/lenses/schukin-boundaries.md +108 -0
  11. smd_engine/assets/lenses/schukin-interface-tax.md +102 -0
  12. smd_engine/assets/lenses/triz-contradictions.md +95 -0
  13. smd_engine/assets/procedures/README.md +38 -0
  14. smd_engine/assets/procedures/field-result.md +56 -0
  15. smd_engine/assets/procedures/functional-plan.md +182 -0
  16. smd_engine/assets/procedures/ingest-transcript.md +118 -0
  17. smd_engine/assets/procedures/positional-construction.md +188 -0
  18. smd_engine/assets/procedures/problematization.md +184 -0
  19. smd_engine/assets/procedures/qualification-pass.md +226 -0
  20. smd_engine/assets/procedures/reflexive-protocol.md +170 -0
  21. smd_engine/assets/procedures/small-situation.md +222 -0
  22. smd_engine/assets/procedures/solo-session.md +174 -0
  23. smd_engine/assets/procedures/theses-to-board.md +91 -0
  24. smd_engine/assets/procedures/visionary-tract.md +266 -0
  25. smd_engine/assets/profiles/classic-two-boards.yaml +67 -0
  26. smd_engine/assets/profiles/program-three-boards.yaml +92 -0
  27. smd_engine/assets/roles/README.md +49 -0
  28. smd_engine/assets/roles/actors.md +72 -0
  29. smd_engine/assets/roles/game-technician.md +63 -0
  30. smd_engine/assets/roles/methodologist.md +100 -0
  31. smd_engine/assets/roles/researcher.md +44 -0
  32. smd_engine/assets/roles/visionary.md +75 -0
  33. smd_engine/cli.py +811 -0
  34. smd_engine/compare.py +321 -0
  35. smd_engine/eval.py +140 -0
  36. smd_engine/migrate.py +179 -0
  37. smd_engine/pack.py +185 -0
  38. smd_engine/profile.py +583 -0
  39. smd_engine/records.py +137 -0
  40. smd_engine/render/__init__.py +12 -0
  41. smd_engine/render/assets/frames.css +42 -0
  42. smd_engine/render/assets/frames.js +46 -0
  43. smd_engine/render/assets/graph.css +31 -0
  44. smd_engine/render/assets/graph.js +246 -0
  45. smd_engine/render/frames.py +292 -0
  46. smd_engine/render/frames_page.py +184 -0
  47. smd_engine/render/frames_text.py +106 -0
  48. smd_engine/render/graph.py +342 -0
  49. smd_engine/render/graph_ui.py +58 -0
  50. smd_engine/render/html.py +138 -0
  51. smd_engine/render/index.py +303 -0
  52. smd_engine/render/layout.py +301 -0
  53. smd_engine/render/light.py +124 -0
  54. smd_engine/render/markdown.py +157 -0
  55. smd_engine/render/mermaid.py +57 -0
  56. smd_engine/render/sessionflow.py +223 -0
  57. smd_engine/render/svg.py +544 -0
  58. smd_engine/render/text.py +284 -0
  59. smd_engine/render/vault.py +322 -0
  60. smd_engine/revise.py +127 -0
  61. smd_engine/schemas/__init__.py +0 -0
  62. smd_engine/schemas/board_patch.schema.json +81 -0
  63. smd_engine/schemas/board_set.schema.json +304 -0
  64. smd_engine/schemas/source_manifest.schema.json +40 -0
  65. smd_engine/schemas/taxonomies.schema.json +32 -0
  66. smd_engine/screen.py +71 -0
  67. smd_engine/sources.py +145 -0
  68. smd_engine/validate/__init__.py +205 -0
  69. smd_engine/validate/context.py +99 -0
  70. smd_engine/validate/hints.py +301 -0
  71. smd_engine/validate/hypotheses.py +49 -0
  72. smd_engine/validate/manifest.py +30 -0
  73. smd_engine/validate/ontology.py +43 -0
  74. smd_engine/validate/signoffs.py +130 -0
  75. smd_engine/validate/structure.py +294 -0
  76. smd_engine/validate/taxonomies.py +74 -0
  77. smd_engine/validate/theses.py +73 -0
  78. smd_engine-0.3.7.dist-info/METADATA +178 -0
  79. smd_engine-0.3.7.dist-info/RECORD +82 -0
  80. smd_engine-0.3.7.dist-info/WHEEL +4 -0
  81. smd_engine-0.3.7.dist-info/entry_points.txt +2 -0
  82. smd_engine-0.3.7.dist-info/licenses/LICENSE +21 -0
@@ -0,0 +1,116 @@
1
+ ---
2
+ id: design-chain
3
+ title: "Design chain for a pass between positions (goal, beneficiary, subject, form, technologies, conditions, result)"
4
+ version: 0.2.1
5
+ source: "Report P, a design study of organised transfer prepared for the program by a model run (local, not in the repo): its closing design chain and its classification rule, as read in a local digest; generalised by this lens"
6
+ route: smd
7
+ offered_by: [positional-construction, functional-plan]
8
+ ---
9
+
10
+ # Design chain for a pass between positions
11
+
12
+ A lens for designing how something passes from one position to another, so that the pass is checked link by link: what is to be achieved, for whom, what exactly passes, in what form it is held afterwards, with what instruments, under what conditions, and how the result will be seen.
13
+
14
+ The source is report P, a design study of organised transfer, prepared for the program by a model run. It is written as comparative law and service design, with no SMD vocabulary. It ends with a design chain and states one rule for classifying what people call a purpose. This lens keeps both and widens "subject of transfer" to whatever passes between positions. Every widening is marked. The report's own content (its tables, country sections and the roles it names) is not reproduced.
15
+
16
+ Marks: **[P]** stated in report P as the digest reads it; **[X]** this lens's extrapolation; **[?]** not shown in the digest or open in the source.
17
+
18
+ ## The chain and the rule
19
+
20
+ The chain, in the order P closes with [P]:
21
+
22
+ 1. goal (in P, a preservation goal);
23
+ 2. beneficiary;
24
+ 3. subject of transfer;
25
+ 4. form of ownership and management;
26
+ 5. enabling technologies;
27
+ 6. mandatory conditions;
28
+ 7. observable result.
29
+
30
+ The rule [P]: classify purpose, method of transfer and enabling instrument separately. A platform, a loan, a register and an advisory service serve purposes but are not purposes. In this lens:
31
+ - **purpose**: what is to be preserved or achieved, in whose interest;
32
+ - **method**: the way the subject passes (sale, gift, lease, delegation, split into parts) [X wording];
33
+ - **instrument**: what makes a method workable (a service, a loan, a register, a rule of relief).
34
+
35
+ Subject of transfer, generic reading [X]: whatever passes between positions. It may be an asset, a task, a product, a place in a chain, a responsibility. P splits what passes into four subjects and says that one method of passing can change only the first [P]. This lens reads the four generically [X]:
36
+ - (a) the formal right: who may dispose;
37
+ - (b) authority to act and decide;
38
+ - (c) knowledge and relations;
39
+ - (d) obligations and benefits: what is owed and what is earned.
40
+
41
+ Passing (a) alone changes only (a) [P, generalised].
42
+
43
+ ## When to use
44
+
45
+ - A move needs something to pass between positions and the group must design the pass: a right, a task, a product, a place in a chain. In the engine: `positional-construction` section 3 (the `flow` relations between positions: what passes, from whom, to whom) and `functional-plan` section 3 (who performs, pays and receives).
46
+ - When the first answer to "what is the goal?" is a tool ("an exchange", "a loan", "a platform"). The classification rule exists for that case.
47
+ - Not to describe a practice that already exists (`small-situation`), and not to rank purposes across a whole field. Report P ranks nothing [P].
48
+
49
+ ## Questions
50
+
51
+ 1. **Goal.** What is to be preserved or achieved, and what would the parties regard as an unacceptable loss? Ask the loss first, before any form of the pass is named [P: the first interview opens with it]. Write the goal as a purpose, not as a method or an instrument.
52
+ 2. **Classification.** For each item named so far, is it a purpose, a method of passing or an instrument? Move any misfiled item to its class, and say what purpose it serves. [P]
53
+ 3. **Beneficiary.** Whose interests decide? Who else bears the loss or the cost? Where two beneficiaries want different goals, which goals conflict? [P: the table of purposes names whose interests decide; P has a section on conflicts]
54
+ 4. **Subject.** What passes, from which position to which? For each of (a) to (d): does it pass, when, and what stays behind or is lost? [P, generalised X]
55
+ 5. **Form.** After the pass, who holds the right, who acts, and how are the two tied? May they be separated? [P: "ownership and management form"; the wording is generalised X]
56
+ 6. **Instruments.** Which instruments make the form workable? For each: which purpose it serves, who performs it, and who pays. Where one performer plays two operator roles, is the conflict disclosed, and is the fee logic? [P] P separates five operator roles and allows combining them only with disclosed conflicts and fee logic. The digest names them without defining them, and this lens does not reproduce the names: use the question only to check that roles are not silently combined [?].
57
+ 7. **Conditions.** Which rules must hold: law, programme rules, contracts, tax conditions? For each: source, addressee, date, supervisor, and the consequence of breach. Is it in force, deferred, or only proposed? [P: the legal register; in-force, deferred and proposed rules are kept apart]
58
+ 8. **Result.** What would be seen, by whom and by when, so that the group could say the goal was met? P suggests reading results at one, three and five years [P]; the group chooses its own timing. Its success criteria are proposals, not official indicators [P].
59
+ 9. **Chain check** [X]. Read the chain forward. Is any link empty: a goal with no beneficiary, a subject with no receiving position, a form with no one acting, an instrument with no performer, a condition with no source, a result nobody will observe?
60
+
61
+ ## Output slots
62
+
63
+ Every element carries `lens: design-chain`, `voice: ai`, `epistemic: hypothesis` unless a registered source supports it (then `cites`). `seen_from` is the position the design is drawn from. All are proposals until the human decides.
64
+
65
+ | Answer | Kind | Board | Fields and links |
66
+ |---|---|---|---|
67
+ | Q1 goal | `goal` | `od` | `seen_from` the position whose goal it is |
68
+ | Q1 unacceptable loss | `note` | `od` | label "unacceptable loss: ..." |
69
+ | Q2 class | no new element | | relabel or move the misfiled item; say the class in the reply |
70
+ | Q3 beneficiary | `position` or `place_for_others` | `od` | a `position` only if the human works from it or an AI position is agreed |
71
+ | Q3 conflict of goals | none | | `opposes` relation between the two `goal` elements. A `problem` thesis only if the group itself states two justified, opposite claims |
72
+ | Q4 a subject | `other` | `oo` | label "subject: (a) formal right of ...", (b), (c) or (d); `flow` from giving position to it, and from it to receiving position |
73
+ | Q4 a subject that nobody carries after the pass | `gap` | `od` | `of: function`: the function of carrying it is missing [X] |
74
+ | Q5 form | `concept` | `oo` | label "form: ..." |
75
+ | Q6 an instrument | `function` | `oo` | `performed_by` its performer (a position or a place for others); `seen_from` the position the design is drawn from; payer and receiver as `flow` relations, as in `functional-plan` section 3 |
76
+ | Q6 a missing performer | `gap` | `od` | `of: position` |
77
+ | Q6 operator roles combined | `note` | `oo` | label "combined roles: ...; conflict disclosed: yes or no" |
78
+ | Q7 a condition | `standard` | `oo` | label begins "in force", "deferred" or "proposed"; `cites` the source, else `epistemic: unverified` |
79
+ | Q8 the result | H record | | `assumes` (the chain works), `action`, `observe` (the result and its timing), `revise_if`, `targets` the goal. No result is written until the field gives one |
80
+ | Q9 an empty link | `gap` | `od` or `oo` | `of`: `position` for beneficiary, receiver or actor; `function` for instrument; `method` for the way of passing; `product` for a result nobody receives [X] |
81
+
82
+ A requirement's five register fields (source, addressee, date, supervisor, breach) go in the reply as a table. The record holds one `standard` per requirement, with the source in `cites`.
83
+
84
+ ## Limits
85
+
86
+ - Report P was prepared by a model run and names no author in its text. The digest says nearly every statement in it links to a primary source and assessed the evidence quality; the links were not re-checked here. Whether the report's owners accept its being cited as a source in a committed lens file is open.
87
+ - P says its classification is an analytic construct, not an official standard, and that its success criteria are proposals. It cannot rank jurisdictions, and it notes missing deal, survival and budget data [P].
88
+ - The order of the chain and the one, three and five year readings are P's recommendations. The digest shows no argument that the chain is complete or that the order matters [?].
89
+ - P covers the law and programmes of several countries. Whether a given rule applies to a given case is unchecked: the lens asks for the source and the status, it does not supply them.
90
+ - The generic reading of the subject (a) to (d), and of "goal", "form" and "method", is this lens's [X]. P writes for organised transfer of an enterprise. Not reproduced here: P's tables of purposes and of functions that transfer technologies must cover, its country sections and its correction register. A lens for a transfer in one jurisdiction would cite those directly.
91
+ - P is not an SMD text. `route: smd` means only that the engine uses it on SMD boards. Its split of purpose, method and instrument is a classification, not a scheme in the classic sense (product, material, means, method).
92
+ - The data model has no kind for "what passes", so subjects use `other`. This is reported as a possible format addition, not met with a new field.
93
+
94
+ ## Example (invented bakeries case)
95
+
96
+ A shared plant takes over the dough ordering that each bakery did by phone. A proposal for questions 1, 4, 6 and 7:
97
+
98
+ ```yaml
99
+ - {id: g-order, board: od, kind: goal, label: "dough ordering keeps working when the bakeries stop ordering by phone",
100
+ seen_from: p-organiser, voice: ai, epistemic: hypothesis, lens: design-chain}
101
+ - {id: sub-auth, board: oo, kind: other, label: "subject: (b) authority to place orders with the mill",
102
+ seen_from: p-organiser, voice: ai, epistemic: hypothesis, lens: design-chain}
103
+ - {id: sub-know, board: oo, kind: other, label: "subject: (c) which bakeries need an early delivery",
104
+ seen_from: p-organiser, voice: ai, epistemic: hypothesis, lens: design-chain}
105
+ - {id: gap-know, board: od, kind: gap, of: function, label: "who carries the knowledge of early deliveries after the pass?",
106
+ seen_from: p-organiser, voice: ai, epistemic: hypothesis, lens: design-chain}
107
+ - {id: fn-order, board: oo, kind: function, label: "order consolidation service for members",
108
+ seen_from: p-organiser, performed_by: p-plant, voice: ai, epistemic: hypothesis, lens: design-chain}
109
+ - {id: std-min, board: oo, kind: standard, label: "in force: the mill's minimum order size",
110
+ seen_from: p-organiser, voice: ai, epistemic: unverified, lens: design-chain}
111
+ relations:
112
+ - {from: p-bakery, to: sub-auth, kind: flow, label: "gives"}
113
+ - {from: sub-auth, to: p-plant, kind: flow, label: "receives"}
114
+ ```
115
+
116
+ Question 2 would flag a first answer of "a shared ordering app" as an instrument, not a goal. Question 8 then becomes an H record, for example `observe: orders placed late per month, read after one, three and six months`.
@@ -0,0 +1,113 @@
1
+ ---
2
+ id: fliamer-diamond
3
+ title: "Diamond of the big situation (functions, products, consumption, new technical solutions)"
4
+ version: 0.1.1
5
+ source: "Fliamer, module-1 workspace slides 3-6 (slide 6 diagram and the big-situation prompt it names; slides 3-5 for the field of division of labour and its technologization); SessionFlow frame 03 for the takt scope"
6
+ route: smd
7
+ offered_by: [visionary-tract, functional-plan]
8
+ ---
9
+
10
+ # Fliamer's diamond of the big situation
11
+
12
+ A lens for laying out a wider system of activity: which complexes of activity make it up, what functions they carry, what they produce, who consumes it, and which technical solutions change them. The source is a deck of six slides and a prompt it names. This file reads the deck as a local digest of the slides describes it (the digest is not in the repo), and keeps the digest's uncertainty marks.
13
+
14
+ Marks used below:
15
+ - **[S]** stated in the slides, as read in the digest;
16
+ - **[R]** on a reconstructed slide. Slides 2 and 5 are redrawn from slide 1 and some labels are uncertain; the digest says to check them against slide 1;
17
+ - **[X]** this lens's own extrapolation, to confirm with the organisers;
18
+ - **[?]** open in the source.
19
+
20
+ ## What the source gives
21
+
22
+ - Slide 6 names a second prompt, "analysis of the big situation" (v6, not seen by the digest). Input: the formulation of the group's field of work, plus materials of group discussions, reports and answers to questions. Output: foci (очаги) described as complexes of activities and the functions they carry, and how activities change through (А) new functions, products and consumer categories, (Б) new technology that cheapens delivery of a function, (В) new technology that customises products, (Г) institutional norms, technologies and organisational structures that become demanded [S].
23
+ - The slide's diagram is a diamond with four vertices: functions in the chain, products, consumption and consumers, new technological solutions [S]. The digest lists the vertices only. It does not describe edges, order or direction [?].
24
+ - Slide 3 sets the field: a "new industry" is an area of the division of labour (РТ) subjected to mechanisation or automation (технологизация), thought of systemically by analysts. A group's theme is expected to turn out plural: "not a complex but complexes" [S]. "РТ" is never expanded; reading it as "разделение труда" (division of labour) is the digest's inference [?].
25
+ - Slide 4 shows a sample output in card form, one card per complex: an integrator, four numbered links of the division of labour, notable participants, a result, numbered source codes with footnotes, and a line on what the difference between complexes means. Its point: a shared technology base is not one industrial chain, because customer, functions, infrastructure and accepted result differ [S]. That the cards show the expected output of the slide 6 prompt is the digest's reading ("evidently") [?].
26
+ - Slide 5 gives three movements: set the whole area as a complex of activities; cut out a place in the object for oneself; read the situation and what it demands, which feeds the revising of one's intent. Beside the second movement: two computations that set "what is in the object", one from the situation and one from raising the efficiency of resource use [R]. The digest does not say how either is done [?].
27
+
28
+ ## When to use
29
+
30
+ - The group has a theme or a field and wants its big situation laid out before choosing a place in it. In the engine: `visionary-tract` step 1 (the system of activity to which the normality applies: questions 1 and 2) and step 4 (the bridge: question 6, the change channels); `functional-plan` section 2 (the chain: questions 3 to 5) and section 5 (material on how the same chain is arranged elsewhere). Which steps get the lens is the engine's choice **[X]**; the slides tie the diamond to the big situation, not to named procedure steps.
31
+ - Not on first-takt material. SessionFlow frame 03 scopes the first takt to the small situation, and the big situation belongs to the second takt (digest, frame 03 and Fliamer). If the only material is a small-situation message, keep the big-situation items as questions for the next takt.
32
+ - Not to describe the group's own practice: that is `small-situation`.
33
+ - Expect more than one complex. A result with a single complex is a finding that needs a reason, not the default [S, slide 3].
34
+ - Without registered material on the field, every answer is an AI hypothesis. Say so at the start.
35
+
36
+ ## Questions
37
+
38
+ 1. **Field.** What area of the division of labour does the theme point to, in the group's words, and which part of it is being mechanised or automated? [S]
39
+ 2. **Complexes.** Is it one complex or several? For each: what is it called, who integrates it, who are the notable participants, what is its accepted result? [S]
40
+ 3. **Functions in the chain.** For each complex, which links of the division of labour does it contain, in order? Who performs each, and what passes to the next? The sample cards show four links; that number is not a rule [S, X].
41
+ 4. **Products.** What does each link deliver, and what does the whole chain deliver? Which product of one link is the material of the next? [S for the vertex; the chain reading follows `functional-plan` and GP1975, X]
42
+ 5. **Consumption and consumers.** Who consumes each product, for what, and in which categories? Which category is new? [S]
43
+ 6. **New technical solutions.** Which technologies are present or arriving? For each, through which channel does it change the complex: new functions, products or consumer categories (А); cheaper delivery of an existing function (Б); customised products (В); demanded norms, technologies or organisational structures (Г)? [S]
44
+ 7. **Difference between complexes.** If there is more than one: what differs, customer, functions, infrastructure or accepted result? Is a shared technology base being read as one chain? In one sentence, what does the difference mean for someone who wants a place in the field? [S]
45
+ 8. **Empty places.** Where in a chain does no one perform, no one pay, or no one consume? [X; the check is `functional-plan` section 4. Choosing a place for oneself is not asked here: it belongs to `visionary-tract` step 5.]
46
+ 9. **Two computations** (optional). What is "in the object" if counted from the situation, and what if counted from raising the efficiency of resource use? [R, ?] Record the answer as given; the digest gives no method.
47
+
48
+ ## Output slots
49
+
50
+ Every element carries `lens: fliamer-diamond`, `voice: ai` and `epistemic: hypothesis`, unless a registered source supports it: then `cites` is set and `epistemic` follows the source. `seen_from` is the position the view is drawn from (`visionary-tract` section 0, owner of the vision). All elements are proposals until the human decides.
51
+
52
+ | Answer | Kind | Board / half | Fields and links |
53
+ |---|---|---|---|
54
+ | Q1 the field | `situation` | `s`, big | label "field: ..." |
55
+ | Q2 a complex | `situation` | `s`, big | label "complex: ..." |
56
+ | Q2 integrator, participants | `place_for_others` | `od` | one per actor; a `position` only if the human works from it |
57
+ | Q2 accepted result | `fact` | `s`, big | label "result: ..."; `cites` required, else `epistemic: unverified` |
58
+ | Q3 frame of a complex (if none in the record) | `frame` | `oo` | `frame_state: old`: the complex exists in the world; the group's own new frame is not touched |
59
+ | Q3 a link of the chain | `function` | `oo` | `in` the complex's frame; `flow` to the next function, labelled with what passes; `performed_by` its performer, a `place_for_others` for an outside actor; `seen_from` stays the viewing position |
60
+ | Q4 a product | `other` | `oo` | label "product: ..."; `produces` from its function |
61
+ | Q5 consumer category | `place_for_others` | `od` | label says "new" for a new category; `flow` from the product |
62
+ | Q5 consumption | `fact` | `s`, big | label "consumption: ..." |
63
+ | Q6 a technical solution | `concept` | `oo` | label "technical solution: ..." |
64
+ | Q6 a demanded norm | `standard` | `oo` | `cites` or `epistemic: unverified` |
65
+ | Q6 a demanded organisational structure | `note` | `s`, big | label "demanded structure: ..." |
66
+ | Q6 a change channel | `situation` | `s`, big | label "change А|Б|В|Г: ..."; `refers` to the complex and to the technical solution |
67
+ | Q7 difference, its meaning | `note` | `s`, big | labels "difference: ...", "meaning of the difference: ..." |
68
+ | Q8 an empty place | `gap` | `od` or `oo` | `of` as in `functional-plan` section 4: `position`, `function`, `material`, `means`, `method` or `product` |
69
+ | Q9 the two computations | `note` | `oo` | label "in the object from the situation: ..." or "... from resource efficiency: ..." |
70
+
71
+ Rules:
72
+ - No named participant, company or figure without a registered source. Where the source does not name one, write "not named". The sample cards name actors; an AI filling such a card from memory invents them (frame 03: no invented counterparties).
73
+ - Complexes are not merged. Two complexes with different customers or results stay two elements (Q7).
74
+ - A thesis from a session that answers these questions may carry `lens: fliamer-diamond` too.
75
+ - Hypotheses about links nobody has checked are written as H records, as in `functional-plan` section 7. Each H carries `lens: fliamer-diamond`.
76
+
77
+ ## Limits
78
+
79
+ - The diamond is given as four vertices. Whether it is asked clockwise, as a cycle, or in any order is not described; the order of questions 3 to 6 is this lens's [X].
80
+ - The prompt v6 was not seen. This lens follows the description on slide 6, not the prompt text, and is not a copy of it.
81
+ - The two computations on slide 5, and the unlabelled figure with "?" on the same slide, are unexplained [R, ?].
82
+ - The slides give no cadence, roles, tests or criteria: no rule for when complexes are one or two, none for ranking them, none for what counts as a "new" function.
83
+ - Slide 4 is a sample of the expected output, not an output of the prompt [?]. Its example complexes are not reproduced here.
84
+ - The source links the diamond to the revising of intent (slide 5) but not to the four structural moves. Any `move` on these elements would be the engine's reading, not Fliamer's.
85
+ - The data model has no `product` kind, so products use `other`. This is reported as a possible format addition, not met with a new field. A function's outside performer is carried by `performed_by`, which the format now has; the lens does not use `belongs` for it.
86
+ - The lens gives structure. Facts about real complexes need sources. The sample cards on slide 4 cite numbered sources with footnotes; the lens supplies none.
87
+
88
+ ## Example (invented bakeries case)
89
+
90
+ Question 2 to 5 on one complex, as an AI proposal:
91
+
92
+ ```yaml
93
+ - {id: cx-central, board: s, half: big, kind: situation, label: "complex: central production for chains",
94
+ seen_from: p-organiser, voice: ai, epistemic: hypothesis, lens: fliamer-diamond}
95
+ - {id: f-central, board: oo, kind: frame, frame_state: old, label: "central production for chains",
96
+ seen_from: p-organiser, voice: ai, epistemic: hypothesis, lens: fliamer-diamond}
97
+ - {id: place-central, board: od, kind: place_for_others, label: "central plants of the chains",
98
+ seen_from: p-organiser, voice: ai, epistemic: hypothesis, lens: fliamer-diamond}
99
+ - {id: fn-c-bake, board: oo, kind: function, label: "baking at scale", in: [f-central],
100
+ seen_from: p-organiser, performed_by: place-central, voice: ai, epistemic: hypothesis, lens: fliamer-diamond}
101
+ - {id: fn-c-ship, board: oo, kind: function, label: "night delivery to chain stores", in: [f-central],
102
+ seen_from: p-organiser, performed_by: place-central, voice: ai, epistemic: hypothesis, lens: fliamer-diamond}
103
+ - {id: pr-c-bread, board: oo, kind: other, label: "product: par-baked bread",
104
+ seen_from: p-organiser, voice: ai, epistemic: hypothesis, lens: fliamer-diamond}
105
+ - {id: place-chain, board: od, kind: place_for_others, label: "chain store buyer",
106
+ seen_from: p-organiser, voice: ai, epistemic: hypothesis, lens: fliamer-diamond}
107
+ relations:
108
+ - {from: fn-c-bake, to: fn-c-ship, kind: flow, label: "baked bread"}
109
+ - {from: fn-c-bake, to: pr-c-bread, kind: produces}
110
+ - {from: pr-c-bread, to: place-chain, kind: flow, label: "delivered fresh"}
111
+ ```
112
+
113
+ Question 6 then asks, for example, whether a new oven type cheapens baking per loaf (channel Б) or lets the chain order bread to its own recipe (channel В). The answer becomes a `concept` and a `situation` labelled "change Б: ...". It stays a hypothesis until a source is registered.
@@ -0,0 +1,104 @@
1
+ ---
2
+ id: khaprov-levels
3
+ title: Seven levels of management complexity and three kinds of complexity
4
+ version: 0.1.0
5
+ source: "Khaprov, expert lecture on the entrepreneur as organizer of complexity, program day 4, read through a local digest of the automatic transcript and the Q&A file (digest sections 1, 2.1-2.3, 2.5, 4, Q&A 1-2 and 10; the digest is not in the repo); Khaprov in the text below means that lecture"
6
+ route: smd
7
+ offered_by: [positional-construction, functional-plan]
8
+ ---
9
+
10
+ # Khaprov: levels and kinds of complexity
11
+
12
+ A lens that asks at which level of management complexity a problem is decided, who in the case acts at that level, and how developed the three kinds of complexity are. It does not give an answer. It gives the group questions whose answers are checked against its own materials.
13
+
14
+ Terms are Khaprov's, from a lecture heard through an automatic transcript. Where the transcript is unclear, the item is marked **[unverified]** and the source has to be checked against the recording or slides before it is quoted.
15
+
16
+ ## When to use
17
+
18
+ - In positional construction (section 2, the positional set), when a position is described by what it does and nobody has asked whether it acts at the level its task needs, or when the group says a problem is "technical" or "organizational" and cannot say which decision would remove it.
19
+ - In the functional plan (section 4, empty places), when a function has no performer and the question is whether the missing performer belongs at a lower or a higher level than the others.
20
+ - Not in `small-situation`: that procedure writes only the small half, no gaps and no concepts, and takes only the scale question (`khaprov-ontology`, question 1).
21
+ - When a plan puts most of its effort into equipment, and the group wants to see what is missing around it.
22
+ - Do not use it as an organization chart or a ranking of people. Khaprov's levels are levels of complexity of the information and decisions managed, not rank.
23
+
24
+ ## What the source gives
25
+
26
+ Seven levels of management complexity ("7 уровней сложности управления"). Only the end points are numbered in the lecture; levels 2 to 6 take their numbers from the order of the list in the Q&A.
27
+
28
+ | # | Level | What the source says |
29
+ |---|---|---|
30
+ | 1 | objects (объект) | physical things; executors start and stop machines; the operator picks the workpiece, not the part to make |
31
+ | 2 | projects (проект) | the head of a project or a shop decides which part is made, not for which product |
32
+ | 3 | programs (программа) | the product is decided above the project head; **no definition or example** in the source |
33
+ | 4 | strategy (стратегия) | example "entering financial markets"; strategy resolves up to about a third of the uncertainty |
34
+ | 5 | politics (политика) | **no definition or example** in the source |
35
+ | 6 | culture, or axiology (культура, аксиология) | **no definition or example** in the source |
36
+ | 7 | ontology (онтология) | what exists and what does not; needed most by founders and shareholders |
37
+
38
+ - Direction: the lower the level, the more concrete (matter has mass and inertia); the higher, the more abstract, because the work is on information. Each level has its own uncertainty.
39
+ - Every manager, director and founder manages information; only level 1 touches physical objects.
40
+
41
+ Three kinds of complexity of an enterprise ("как нейтрон, протон и электрон"):
42
+
43
+ | Kind | About |
44
+ |---|---|
45
+ | technical | objects: machines, products, buildings |
46
+ | sociodynamic (социодинамическая) | people: roles, communications, processes, documents |
47
+ | conceptual (концептуальная) | concepts the people act by |
48
+
49
+ - "People cannot act more complexly than the concepts built into them." Objects are changed by people, and people are governed by concepts.
50
+ - The levels are read against the three kinds (a 3 x 7 matrix). A firm strong in the technical kind and near zero in the other two has a smaller total than a balanced one. The source gives no content for the cells.
51
+ - Khaprov's claim that firms over-invest in technical complexity and that investment efficiency is low (about 15 percent) is a figure from the transcript **[unverified]**.
52
+
53
+ Transitions between levels. The source states no formal transition rule. It implies three things:
54
+ - each level fixes the choice space of the level below (workpiece, part, product, market);
55
+ - a wrong decision at a high level is not repaired at a lower one (the example is a phone maker that was not worse in objects, projects or programs, and spent more on research, lost to a competitor with a different answer to "what are we making"; the spending figures are ASR numbers);
56
+ - movement up runs through concepts: old or simple concepts keep people from rearranging objects or making other products.
57
+
58
+ Who works at which level:
59
+ - operators at level 1, foremen and shop heads at level 2;
60
+ - top managers need ontology; middle managers need a simplified version that shows the functions of the whole;
61
+ - managers who were executors tend to do low-level work themselves, so firms are staffed at the bottom and thin at strategy, politics, culture and ontology (the source's last clause here is garbled **[unverified]**);
62
+ - an entrepreneur is management of a higher level, or management with a large competence for working outside certainty; "manager" is a position inside an entrepreneurial organization of activity. Khaprov agreed to this wording from a participant.
63
+
64
+ Systems of systems (the third block of the lecture): at the technological order he describes, branches merge into one project, controlled through situation centers in real time. A whole of this kind is held by few actors; the others choose which of them to stand under. His positioning of states is opinion, not method. The usable part is the question "target-positing" (the spelling "целополагание" is as in the transcript; the sense, positing the whole, is inferred **[unverified]**): not one goal per actor, but what the whole is and who in the existing systems (banks, state, suppliers) supports you.
65
+
66
+ ## Questions
67
+
68
+ 1. At which level of complexity is this question decided? Name the decision that would answer it and the choice space that decision fixes below it.
69
+ 2. Who in the case acts at that level? Is there a position that holds it, or does the work fall to a position at a lower level that is doing it as a side task?
70
+ 3. If the answer to question 2 is "nobody", is the missing performer a gap in the structure, or is the group missing the knowledge needed to say?
71
+ 4. For each of the three kinds (technical, sociodynamic, conceptual), what exists today at the level in question? Which cells are filled and which are empty?
72
+ 5. Where did the group's effort and money go: into which kind? Is the balance between the kinds the same as the balance the task needs?
73
+ 6. Which concept do the people involved act by? Does it allow the change the group wants, or does it keep people from rearranging objects?
74
+ 7. Going up: which decision one level higher would make this problem not arise? Going down: which choice space does the present decision leave, and does it leave enough?
75
+ 8. If the problem sits at the level of a previous decision that cannot be repaired lower down, what is that decision and who made it?
76
+ 9. Does this case have a whole that spans several systems? What is that whole, and who in the existing systems (finance, state, suppliers, customers) supports it? List them as places for others, not as parties already agreed.
77
+ 10. Is the entrepreneurial function (working outside certainty, deciding at the top level) held by someone, and is it distinct from the manager's position in the case?
78
+
79
+ ## Output slots
80
+
81
+ Every element carries `lens: khaprov-levels`. Kinds and fields are those of `docs/data-model.md`.
82
+
83
+ | Answer | Kind, board, field |
84
+ |---|---|
85
+ | The level at which the problem is decided (Q1, Q7, Q8) | `note`, `s`, half `small`; `label` begins "level N (name): ..." and `epistemic: hypothesis` until the group confirms; `seen_from` the position that states it |
86
+ | Who acts at the level (Q2) | a `position` on `od`, or a `shift` relation between positions where the work moved down a level |
87
+ | Nobody acts at the level (Q2, Q3) | `gap` on `od` with `of: position`; if the group lacks the knowledge to say, `kind: question` on the thesis instead |
88
+ | One cell of the matrix, a kind at a level (Q4) | `fact` on `s`, half `small`, `label` begins "technical \| sociodynamic \| conceptual at level N: ...", `epistemic` as is; an empty cell is a `note` on `s`, half `small`, label "empty: technical \| sociodynamic \| conceptual at level N"; a `gap` with `of` only if the group itself names the scheme block that is missing |
89
+ | An imbalance between kinds (Q5) | `note` on `s`, half `small`, citing the facts it rests on in the label; or a thesis with `kind: problem`, `belt: m`, `feeds` naming the cells |
90
+ | The concept people act by (Q6) | `concept` on `oo`, `seen_from` the position whose concept it is |
91
+ | Level up or down (Q7) | candidate move on the new element: `{op: adjoin, from: [<element>], via: "axis: management level (Khaprov)", status: candidate}`. Adjoin is the engine's reading of "add the level axis"; Khaprov does not call it that **(own extrapolation)** |
92
+ | The whole across systems (Q9) | `situation` on `s`, half `big`, label begins "whole: ..."; each supporter a `place_for_others` on `od` |
93
+ | Entrepreneurial function (Q10) | `position` on `od` if held; if not, `gap` with `of: position` |
94
+
95
+ The lens maps no cell to a scheme block. An empty cell of the matrix is not by itself an empty place of the functional scheme (GP-PP), and the source gives no cell contents.
96
+
97
+ ## Limits
98
+
99
+ - Levels 3, 5 and 6 have no definition or example in the transcript. The slides probably hold the full table. Until they are checked, elements for these levels carry `epistemic: unverified`, and the model does not invent content for them.
100
+ - Which level a phrase belongs to is a judgment. Two readers can differ; the lens does not settle it.
101
+ - The source gives no rule for moving from one level to another, no cell contents for the matrix, and no measure for "how developed" a kind of complexity is. The matrix is a prompt for discussion.
102
+ - Figures from the lecture (efficiency percentages, uncertainty shares, company numbers) come from an automatic transcript and are not to be quoted without the recording.
103
+ - The lecture's geopolitical and personal examples are the speaker's opinion and are not used here.
104
+ - Scale (object, ecosystem, market) is a separate axis; see `khaprov-ontology`. The source links scale and level only by example.
@@ -0,0 +1,110 @@
1
+ ---
2
+ id: khaprov-ontology
3
+ title: Three scales, the ontology test and managing not-knowing
4
+ version: 0.1.0
5
+ source: "Khaprov, expert lecture on the entrepreneur as organizer of complexity, program day 4, read through a local digest of the automatic transcript and the Q&A file (digest sections 2.4, 3, 4 items 3-4 and 11, Q&A 6, 8 and 9; the digest is not in the repo); reconciliation of the test with the classic method: docs/method/reconciliation.md section 2 (GP1981)"
6
+ route: smd
7
+ offered_by: [small-situation, visionary-tract, positional-construction, problematization, qualification-pass]
8
+ ---
9
+
10
+ # Khaprov: scales, ontology test, not-knowing
11
+
12
+ A lens for the step "view of oneself" and for the ontology records of a case. It asks at which scale the group works and which scale its target needs, what the group says it makes and what competes with it, and what the group does not know. Output goes to the `ontology` list of the record (fields `object`, `valid_for`, `subjects`, `competes`, `test`) and to a few elements.
13
+
14
+ Terms are Khaprov's, from a lecture heard through an automatic transcript. Items marked **[unverified]** must be checked against the recording or slides before being quoted.
15
+
16
+ ## When to use
17
+
18
+ - At step 5, "view of oneself", of `visionary-tract`, as the grain options of the `rescale` move (questions 1-4).
19
+ - In `positional-construction` section 5, when two or more positions describe one object differently and the group wants one record of what is built and for whom (questions 5-11). The procedure already names the ontology test for `competes`.
20
+ - In `small-situation` section 2, only question 1 (the scale the group works at), and only if the human is unsure of it. The answer goes into the label of the fragment element; the procedure writes no other element from this lens.
21
+ - In `problematization` section 2, questions 12-14, when a difficulty may be a wrongly posed problem. The output is a thesis, not new board elements.
22
+ - In `qualification-pass`, as questions behind a K, with no elements written: criterion C7 (scale and the reason for the concept) takes questions 1-4; the realizability row takes questions 9-11. The K text names the lens id.
23
+ - When the group says "our competitors" without saying what competes.
24
+ - Do not use it to decide which ontology is true. The engine's reading, from the classic method, is that a picture is checked for realizability in activity, not for truth (docs/method/reconciliation.md section 2). Khaprov's own position is stronger: a wrong ontology is fatal. Reading "fatal" as "fails the realizability test" reconciles them, but that is the engine's reading **(own extrapolation)**; Khaprov does not say it.
25
+
26
+ ## What the source gives
27
+
28
+ **Scale (масштаб).** Measured by the complexity handled, not by headcount. Three scales, illustrated with aircraft:
29
+
30
+ | Scale | Name | What the source says |
31
+ |---|---|---|
32
+ | 1 | a technical object | a single product; Khaprov says most firms in his context make objects at this scale |
33
+ | 2 | a production ecosystem | a flow of products with the components and suppliers behind it; suppliers need to be sound well before serial production starts |
34
+ | 3 | the market around the product | suppliers, sales and after-sales, operators, infrastructure; entering means facing a large organization with a few people; needs alliances, accumulated volume, infrastructure, investment and state policy |
35
+
36
+ - "People go to scale 3 with products of scale 1 and with money for that product."
37
+ - The move he names is from the level of the object to the level of the mega-system.
38
+ - Aircraft numbers and market sizes in the lecture are ASR figures **[unverified]**.
39
+
40
+ **Ontology.** What exists and what does not; "the world your enterprise, technology or project lives in"; the algorithm by which that world is arranged. Points the source makes:
41
+ - there are no systems without an ontology: the owner may not know it, but it exists;
42
+ - ontologies can be mixed: objects bought from one, management systems taken from another;
43
+ - groups can work in different ontologies without knowing it, with a risk of conflict;
44
+ - scope varies: a firm, an industry, a city, a civilization; a participant distinguished a "small" and a "big" ontology of a city, which concerns depth;
45
+ - the default failure is to repeat past experience;
46
+ - going into someone else's ontology is called a losing course except for very large actors **[unverified]**;
47
+ - the source gives no procedure for choosing or building an ontology.
48
+
49
+ **The ontology test.** The example: two phone makers; one decided it made a device for voice messages, the other an entrance to a digital universe. Their objects differ because their ontologies differ. A second example: aircraft do not compete (they have no bank accounts); corporations and consortia do. The test, as the engine reads it from these examples **(own formulation)**:
50
+ 1. What do we say we make?
51
+ 2. What does the competitor say it makes?
52
+ 3. Do the objects differ because the ontologies differ?
53
+ 4. Do objects compete here, or corporations and consortia?
54
+
55
+ **Managing not-knowing (управление незнанием).** A stage zero before knowledge management: "Do I have knowledge of all the levels of complexity I need? Maybe I formulate the problem wrongly?" The source says ontology-level thinking is hard for adults to learn, suggests a bridge through technical and mathematical language, and mentions AI simulators in which a founder loads projects, staff and tasks and gets variants of decisions. It gives no further method.
56
+
57
+ ## Questions
58
+
59
+ Scale (view of oneself):
60
+ 1. At which scale does the group work today: one object (one deal, one product), a production ecosystem, or the market around the product? Name the evidence, not the headcount.
61
+ 2. At which scale does the target need to be worked? What does the target's market require that the group does not have: alliances, volume, infrastructure, investment, state policy?
62
+ 3. If scale 1 means going to scale 3, who in the case carries the gap between them, and with what money and products?
63
+ 4. What does the group see at each of the three scales that it did not see at the others?
64
+
65
+ Ontology test:
66
+ 5. In one sentence: what do we say we make or do? Say it separately from each position that takes part (these become the subjects).
67
+ 6. In one sentence: what does the nearest competitor say it makes?
68
+ 7. Do the answers to 5 and 6 differ because of different pictures of the world, or only because of different features of the same object?
69
+ 8. What competes with what here: the products, the firms, or groups of firms? Write it as a statement the group can reject.
70
+ 9. For which set of positions is this picture valid? Which positions would reject it?
71
+ 10. If several positions take part, through which cooperation is the common object built?
72
+ 11. What would show, in activity, that the picture is not realizable? Name the action and the observation (this becomes the hypothesis behind `test`).
73
+
74
+ Not-knowing (stage zero):
75
+ 12. Which levels of complexity (see `khaprov-levels`) does the group need to know, and for which does it know nothing?
76
+ 13. Where might the problem itself be formulated wrongly? Which question would the group ask if it assumed that?
77
+ 14. Which ontology is the group acting in without having named it? Is any management system or tool in the case taken from another picture?
78
+ 15. What is the next step that reduces not-knowing the most, and who takes it?
79
+
80
+ ## Output slots
81
+
82
+ Every element, thesis, hypothesis and ontology record it produces carries `lens: khaprov-ontology`; `smd compare` reads all four. The table applies where the procedure writes elements (`visionary-tract`, `positional-construction`). In `small-situation`, `problematization` and `qualification-pass` see "When to use".
83
+
84
+ | Answer | Kind, board, field |
85
+ |---|---|
86
+ | Scale at which the group works and the one the target needs (Q1-Q4) | `situation` on `s`, half `small`, `label` begins "view of ourselves at scale N: ..."; `move: {op: rescale, from: [<big situation>], via: "scale: object \| ecosystem \| market (Khaprov)", status: candidate}`; relate to the earlier small situation with `refers` (as the visionary tract specifies) |
87
+ | What the target market requires at the next scale (Q2, Q3) | `gap` on `od`, `of` set to the nearest scheme block; or `place_for_others` on `od` for an ally or supplier the case does not have yet |
88
+ | Ontological object (Q5-Q7) | `ontology.object`: one sentence, the common object |
89
+ | Each position's answer to Q5 | `ontology.subjects`: `{position: <position id>, subject: "<that position's answer>"}`; each position must be in `valid_for` |
90
+ | Set of positions the picture is valid for (Q9) | `ontology.valid_for`: ids of `position` elements |
91
+ | What competes with what (Q8) | `ontology.competes`: the statement, in the group's words if it gave them |
92
+ | Competitor's claim (Q6) | `note` on `oo`, `seen_from` the competitor's position if the case has one, else `epistemic: unverified` and no `seen_from`; or a `place_for_others` for the competitor if the case holds one |
93
+ | Cooperation (Q10) | `cooperation` element on `oo`; `ontology.cooperation` points to its id |
94
+ | Realizability test (Q11) | a hypothesis `H` with `assumes`, `action`, `observe`, `revise_if`; `ontology.test` points to its id |
95
+ | The picture in use, as a concept (Q5, Q14) | `concept` on `oo`, `seen_from` the position whose concept it is |
96
+ | Not-knowing (Q12, Q13) | thesis with `kind: question` or `problem`, `belt: m`, `lens: khaprov-ontology`; the hypothesis behind it, if testable, as an `H` |
97
+ | What is not known and where (Q12, Q14) | `gap` with `of` set; or `note` with `epistemic: unverified` when no scheme block fits |
98
+ | The next step against not-knowing (Q15) | `goal` on `od`, `seen_from` the position that takes it |
99
+
100
+ Example for the invented bakeries case (`cases/example/`): the record `O1` there has object "shared production as an asset owned by the bakeries that use it", `valid_for` the owner and the organiser, one subject per position, a cooperation element, a `competes` statement and the test `H1`. Use it as the shape of a finished record.
101
+
102
+ ## Limits
103
+
104
+ - The source gives no procedure for choosing, building or comparing ontologies. The four-step ontology test is read from two examples; the source does not list it as steps **(own formulation)**.
105
+ - The source treats ontology as the algorithm of the world a firm lives in, with a right and a wrong one. The engine records it as valid for chosen positions and tested for realizability (GP1981). Neither is quoted as the other's position.
106
+ - "Subjects" per position (предметы) come from the classic method (GP-OP), not from Khaprov. The lens maps his "what do we say we make" onto them **(own extrapolation)**.
107
+ - The three scales are Khaprov's. They are a different axis from his seven levels; the source relates them only by example. The lens does not give a scale-to-level table.
108
+ - Scale is read from the evidence the group brings. The lens gives no thresholds.
109
+ - Managing not-knowing is a title and a first question in the source, not a method. The questions in the third group above are the engine's way of using it **(own extrapolation)**.
110
+ - Figures and company data in the lecture come from an automatic transcript and are not to be quoted without the recording.
@@ -0,0 +1,83 @@
1
+ ---
2
+ id: scamper-check
3
+ title: SCAMPER as a cross-check of the four structural moves
4
+ version: 0.1.1
5
+ source: Eberle (1971), SCAMPER, from Osborn's idea-spurring checklist (Applied Imagination, 1953); the four moves from Zharnikov (2026), doi:10.5281/zenodo.21653102 (docs/method/structural-moves.md); the mapping between them is the engine's
6
+ route: smd
7
+ offered_by: [visionary-tract]
8
+ ---
9
+
10
+ # SCAMPER as a cross-check of the four structural moves
11
+
12
+ Marks as in `docs/method/triz-systems.md`: **[V]** read in the primary text, **[ANALYSIS]** the engine's reading, **[UNVERIFIED]** not checked against a primary text. Examples use the invented bakeries case.
13
+
14
+ SCAMPER is a checklist of seven prompts for generating variants of a product or idea. The four structural moves (`adjoin`, `rescale`, `respecify`, `glue`) are a small set of operations on a representation. This lens runs the seven prompts after the visionary tract to find candidates that the four-move pass did not produce. The mapping from prompts to moves below is the engine's interpretation, not a claim by Eberle, Osborn or Zharnikov. The method note on Zharnikov's paper (`structural-moves.md`) records no mention of SCAMPER **[UNVERIFIED]**; the paper itself was not searched for it here.
15
+
16
+ The route is `smd`: the moves act inside the classic chain of schematization and idealization (`reconciliation.md` section 9), and the check serves that chain.
17
+
18
+ ## When to use
19
+
20
+ - After the visionary tract (`visionary-tract`, after step 6 and before the hand-over of section 10), when the human has selected at each step and the record holds accepted and rejected move candidates.
21
+ - When the four-move pass gave few candidates, or all of one move type, or when the human feels the options are narrow.
22
+ - Not before the tract: the check needs candidates to compare against, and a position and small situation to work from.
23
+
24
+ The check adds candidates only. It does not rank, does not test whether the four moves are complete, and does not replace the tract's steps. The paper's closure claim is made only where compatibility is decidable; a board is not such a domain, so the four moves are a menu there (`structural-moves.md`, limits).
25
+
26
+ ## The mapping (engine interpretation)
27
+
28
+ Operators as listed in a local digest of an invention-method catalog (not in the repo): Substitute, Combine, Adapt, Modify (Magnify, Minify), Put to other use, Eliminate, Reverse (Rearrange). Eberle's own wording and the content of Osborn's list were not checked against the primary texts [UNVERIFIED].
29
+
30
+ | SCAMPER | Prompt | Counterpart | Reasoning [ANALYSIS] |
31
+ |---|---|---|---|
32
+ | Combine | what can be joined with what? | `glue` | A move only if a shared substructure can be named. The paper's glue is a pullback over a shared substructure, not a mixture, so "put A next to B" without the substructure is not a candidate. |
33
+ | Adapt | what else is like this; what can be borrowed from elsewhere? | `glue` | It starts from our object and looks for another domain, which is how the tract's step 3 works. The two operators differ in direction, not in kind of move. |
34
+ | Modify: Magnify, Minify | make it larger, smaller, more or less frequent | `rescale` | Change of size, frequency or grain maps to rescale. "Modify" in the sense of changing form, colour or meaning has no counterpart. |
35
+ | Reverse, Rearrange | do the opposite; change the order, the roles, the direction | `respecify` | Changing who depends on whom, or in what order, changes the admissible links. Reordering along a time axis may instead be `adjoin` if time was not on the picture. |
36
+ | Put to other use | other users, other purpose | `respecify` | The paper lists exaptation, a thing taking new admissible links, as an example of re-specifying [V, structural-moves.md]. |
37
+ | Substitute | what can be replaced: a participant, material, rule, place? | none as such | A substitution fills the same slot with another filler inside the same representation. It counts as `respecify` only if the replacement changes which links are admissible. |
38
+ | Eliminate | what can be removed or simplified? | none as such | The four moves construct; none deletes. The nearest case is `respecify` that identifies two elements kept apart, which removes one. Compare the "no new elements" demand of `triz-contradictions`. |
39
+ | (no operator) | what axis does the picture hold fixed? | `adjoin` | No SCAMPER prompt asks for a new axis (time, observer, scale). Osborn-style "Magnify" also asks what to add, which may produce an axis by accident [UNVERIFIED wording]. |
40
+
41
+ Summary: five of seven operators have a counterpart (Combine and Adapt to `glue`; Modify to `rescale`; Reverse and Put to other use to `respecify`); Substitute and Eliminate have none; `adjoin` has no operator. The check therefore tests `glue`, `rescale` and `respecify` well, and cannot test `adjoin`: candidates of that move come only from the four-move pass.
42
+
43
+ ## Questions
44
+
45
+ Ask them of the AI visionary's material, with the human. Each question is answered from the record and the session.
46
+
47
+ 1. List the candidates of the tract by move, accepted, rejected and still candidate. Which of the four moves were used, and how many times each?
48
+ 2. Combine: which two things on the boards (two functions, two positions, two models) could be joined? What substructure do they share? If none can be named, drop it.
49
+ 3. Adapt: what else, in another field, is like the garland or the model? Is it a domain already tried at the tract's step 3? If so, what does a second domain add?
50
+ 4. Modify: what if the object were much larger, much smaller, or much more or less frequent: one bakery, a street, a region; once a week, every night?
51
+ 5. Reverse or Rearrange: what if the roles were exchanged, the direction of a dependence reversed, or the steps put in another order? Who would then depend on whom?
52
+ 6. Put to other use: who else could use this arrangement, or for what else could its parts be used?
53
+ 7. Substitute: what could stand in place of one participant, material or rule? Does the substitution change which links are admissible, or only who fills a slot?
54
+ 8. Eliminate: what could be removed with the purpose kept? Does the removal merge two elements, or only drop one?
55
+ 9. For each answer to questions 2 to 8: is it already on the record? If yes, drop it. If no, name the nearest of the four moves and the `via` it would need. If none fits, mark it unplaced.
56
+ 10. Which move got no candidate from SCAMPER (always `adjoin`, possibly others)? Say so plainly, so the human knows the check could not test it.
57
+
58
+ Limits on volume: at most two new candidates per operator, and none for an operator that has nothing new. Do not pad.
59
+
60
+ ## Output slots
61
+
62
+ Every element carries `lens: scamper-check`, `voice: ai`, `epistemic: hypothesis`, and `seen_from` the owner of the vision (the position the tract was drawn for). Put the operator's name at the start of `via`, since the record has no field for it.
63
+
64
+ | Answer | Element kind | Board | Fields |
65
+ |---|---|---|---|
66
+ | New `glue` candidate (Combine, Adapt) | `model` | `oo` | label begins "model from another domain: ..."; `move: {op: glue, from: [...], via: "SCAMPER Combine; shared substructure: ...", status: candidate}` |
67
+ | New `respecify` candidate (Reverse, Rearrange, Put to other use, Substitute, Eliminate when they change links) | `situation` | `s`, `half: big` | label begins "big situation with new quality: ..."; `move: {op: respecify, ..., via: "SCAMPER Reverse; links changed: ...", status: candidate}` |
68
+ | New `rescale` candidate (Modify) | `situation` | `s`, `half: small` | label as in the tract's step 5; `move: {op: rescale, ..., via: "SCAMPER Magnify; grain: ...", status: candidate}` |
69
+ | Unplaced result (Substitute or Eliminate that fits none of the four) | `note` | the board where it belongs | label begins "unplaced by the four moves: <operator>: ..."; no `move` |
70
+
71
+ The kinds and boards repeat those of the tract's steps 3 to 5 so that a candidate from this check is read like one from the tract. `from` names the earlier accepted elements the move acts on, as in the tract. Run the gate of `visionary-tract` section 1 (`uv run smd validate <draft> <previous> --sources <manifest> --hints`) and drop what still fails after two repairs.
72
+
73
+ The human selects. A candidate with a move is accepted by an `accept_move` sign-off by a person or the group; the model does not write it. An unplaced `note` has no sign-off function; the human either restates it in their own words or removes it. All unplaced notes go to the methodologist as a list, since they are the nearest the engine has to evidence about where the four moves stop; one such note proves nothing about closure.
74
+
75
+ Example (invented): after the tract the bakeries record has a `glue` model (a cooperative owning a shared asset) and a `respecify` situation, and no `rescale` candidate. Minify gives "view of oneself: one night of dough for one street, tested before a regional plant" with `rescale`. Reverse gives "the mills deliver dough, not flour, so the first step of baking moves from the bakery to the mill" with `respecify`, `via: SCAMPER Reverse; links changed: who performs the first step`.
76
+
77
+ ## Limits
78
+
79
+ - The seven operators and the bibliographic details (Eberle, 1971; Osborn, 1953) come from a local digest of an invention-method catalog and from general knowledge, not from the primary texts [UNVERIFIED]. Check them before quoting.
80
+ - The mapping is a reading. Other readings are possible: Adapt could be placed beside `respecify`, and Put to other use beside `glue`. Where the mapping is doubtful, the `via` text carries the reason, not the operator name.
81
+ - SCAMPER was devised for products and teaching imagination **[UNVERIFIED]**. That its prompts help with positions, frames and big situations is [ANALYSIS], not shown.
82
+ - Zharnikov's paper is about representations in science and ontology, not group talk in the Shchedrovitsky tradition (`structural-moves.md`). Reading a SCAMPER prompt as a move on a board is the engine's interpretation, to be checked with methodologists.
83
+ - The check cannot test `adjoin`, and finding nothing new from an operator does not show that the four-move pass was complete.