- + Block A7.0 Origins Document (NEW) — pre-history reconstruction before main A7
- + Block A7.5 Domain Application (NEW) — applying findings to a specific use case
- Block A7 reformulated: instead of a single report → a 4-document publication suite (Executive · Main · Origins · Application)
- 11 → 13 skills (+ecosystem-origins-document, +ecosystem-domain-application)
- Pattern card structure formalized in Pillar 14: phenomenon + 5-whys + numbers grid + transferability
Trigger: gap analysis showed the "Zh" case has 6 standalone HTMLs + 4 print versions vs. our single main HTML.
- + Pillar 13 · Provenance Discipline · mandatory provenance audit. Forbids batch reclassification without re-fetching the source
- + Pillar 14 · Coverage Assessment · a formal phase assessing domain coverage across 6 dimensions before synthesis
- + Block A4.0 between A3 and A4 — Provenance Discipline gate
- + Block A4.99 between A4 and A5 — Coverage Assessment gate
- 9 → 11 skills (+ecosystem-coverage-assessment NEW, +ecosystem-analytical-report NEW)
Trigger: the exp-2v2 reclassification trap → user critique → exp-2v3 validation of the corrections (338 entities · 100% web-sourced · GO verdict)
IDEF0 Decomposition of the Ecosystem-Reconstruction Method
The layer beneath the 8 steps of METHOD.html. Every step is decomposed as an IDEF0 block: inputs / controls / mechanisms / outputs + an explicit refinement loop and explicit storage points. The goal — robust work at the intersection of "Claude · files · deterministic functions · user · external tools", without losing the contract between sessions.
A user review of the exp-2 publication report exposed a structural error in the method (the ontology was defined BEFORE reconnaissance). The v4.0 method adds 4 phases + a cross-cutting loop. IDEF0 v3.0 syncs the decomposition.
- New blocks A0 / A1.5 / A3 / A6.5 in the main flow (see the v3.0 context diagram)
- New cross-cutting Ontology-delta feedback loop — feedback from extract/reflect/contradictions back to the A1.5 ontology
- Pillar 11 · Inductive-deductive flow — fixes that reconnaissance precedes ontology (no inverted causality)
- Pillar 12 · Ontology-evolution-log — a continuous ontology-history.md with versioned onto-extensions
- 9 operational skills (vs 5 in v2.2): +2 new (reconnaissance · ontology-design) + 1 expanded scope (publish-draft merges A6.5+A7) + 6 modified → v2.0
Archived copy of v2.2 kept: archive/v3.2-pre-major-revision/methodology/IDEF0-v2.2.html. See REVIEW-AND-CORRECTIONS for the full rationale.
- Block A4 fully operationalized: an 8-phase protocol (A4.1 setup → A4.2 extract per hub → A4.3 F1+F2 merge → A4.4 CH validation → A4.5 F3-F7 → A4.6 DAG-VIZ → A4.7 reflect_block → A4.8 A4-RESULT). The 7-step pipeline_per_hub (research-plan §B3) is now a mandatory part of A4.2.
- New block A4-D · D-stage (centrality validation + CH check scripts). See METHOD.html §08b for details. Includes D1-D6 metrics + CH-N validation scripts with two distance levels for dynasty hypotheses.
- REFLECT block (between iter_N and iter_N+1) — a separate meta-block implementing FINDING #3, the discovery-first iterative cycle. A 6-section reflect_block + iter_{N+1}_decision (GO/STOP/PIVOT). Operationalized in the
ecosystem-reflect-iterskill. - 9th pillar of rigor · ID-reuse pattern for cross-bridge graph integrity (same person/org = same node ID across all hubs).
- 10th pillar of rigor · graph-structure-not-metadata for CH validation (check adjacencies/paths, not label similarity).
- 3 working skills under Pillar 4 "mechanisms" (the deterministic part):
ecosystem-init·ecosystem-plan-research·ecosystem-extract-and-aggregate·ecosystem-reflect-iter.
Why a second level of detail
In METHOD.html the steps are described as stages of work. That is enough to understand what to do. It is not enough to keep the work robust across many runs and sessions — especially when part of the steps runs in an LLM chat, part in files, and part is done manually by the user.
The second layer is needed in order to:
- Fix the contracts. Every step has an explicit input (format, source, validation) and output (format, storage location, provenance). Each next step reads its input from a file, not "from session memory".
- Separate the deterministic part from the LLM part. In each block it is visible what is done by a hard algorithm (template validation, rule-based classification, CI calculation), and what by LLM reasoning. The hard part is reusable and session-independent. The LLM part is replaceable, retunable, restartable.
- Lock in the refinement loop. Inside each block — one unified interaction pattern with the user: questions → draft → agreement → commit. This is not free-form dialogue but a formal "beat".
- Hold rigor across sessions. The LLM session is lost. Files are not. On entry, each block reads its set of anchor files, so a new session starts from the same state the previous one ended at.
The IDEF0 pattern in this form is already proven in projects P33 (MIRA) and DAISY (the AI Chef). There it's a system of agents; here it's a system of ecosystem-reconstruction steps. The structure is the same: 4 arrow types (C/I/O/M) + an explicit loop inside the block + layer separation (business process / utility / meta). The reference is kept in /04_KNOWLEDGE/schemas-and-technologies/idef0-layered-pattern.md.
Notation
For mechanisms inside blocks the following tags are used: LLM Claude reasoning, DET deterministic function / script, USR user action, FILE anchor file (read/written directly).
Context diagram A-0 — the whole pipeline
The top level: the entire P49 method as a single function. What goes in, what governs it, what holds it from below, what comes out.
cases/)
I6 registry of own projects (05_PROJECTS/INDEX.md)
cases/XX/ folder with all artifacts
O2 an updated domain ontology (two-dimensional: P5 × R/P/T/D)
O3 a publication package (brief · HTML · deck · graph)
O4 a gap list for own projects
O5 publication at life.avmakin.com/m2ai/runs/XX (if enabled)
A0 decomposition — 8 blocks
The pipeline breaks down into 8 functional blocks. They run sequentially, but returns between them are possible (for example, on unclosed Competency Questions, a return from A7 to A4).
| Block | Function | Main input → output | Anchor file |
|---|---|---|---|
| A1 | Run parameters | request → parameters.yml | parameters.yml |
| A2 | Research plan | parameters → research-plan.md | research-plan.md |
| A3 | Tracks and allocation | plan → tracks-grid.md | tracks-grid.md |
| A4 | Ontology + knowledge delta | raw materials → ontology.yml · entities.csv · relations.csv · delta.md | ontology.yml |
| A5 | Synthesis and analytics | graph → synthesis.md · analytics.html | synthesis.md |
| A6 | Validation by CQ | synthesis → competency-questions.md | competency-questions.md |
| A7 | Mirror onto own loops | synthesis + portfolio INDEX → mirror-map.md | mirror-map.md |
| A8 | Gap analysis + publication | mirror → gap-analysis.md · publish/ | gap-analysis.md |
On entry, every block reads its input from an anchor file, not from session memory. On exit, every block writes its result to an anchor file, not "leaves it in the chat". This makes the pipeline robust to session changes, switching between chats, and parallel runs.
The universal single-block pattern
All 8 blocks follow one form. This lowers cognitive load: once you understand the pattern, you understand all of them.
If the DoD is not met — the loop repeats.
C1 — the "how to do it" methodology (the METHOD.html section for this block). C2 — the "what should result" output template (the template file). The separation gives two degrees of freedom: you can change the methodology without breaking the output contract, and change the template without rewriting the methodology. This pattern came from the IDEF0 analysis of the AI Chef and proved its robustness.
Detailed expansion · 3 key blocks
I fully expand three blocks where the specifics matter most. The other 5 are described briefly in the same form in the table below.
A1 · Run parameters
templates/parameters.template.yml
C3 Acceptance: 6 parameters filled, the user explicitly confirmed the frame
parameters.yml of the previous run
I3 The cases/ registry — to avoid repeating a topic
I4 v3 Documents and materials on the topic (if at hand)
I5 v3 Links to open sources (web URLs, arxiv IDs, GitHub repos)
I6 v3 Company data sources (CRM exports, internal docs, policies)
I7 v3 The user's working hypothesis (opt., becomes working_hypothesis)
I8 v3 Key questions — what I definitely want to learn (opt.)
cases/XX/parameters.yml (with 6 required + 3 opt. v3)
O2 cases/XX/decisions.log — what was confirmed
O3 cases/XX/sources.yml — typed source registry: documents / web / DBs
O4 Signal "ok · proceed to A2"
parameters.yml · decisions.log · sources.yml
Visual cue — a fill-rate progress (see §06 "two indicators"). If validation fails — return to ②.
A4 · Ontology + extraction + delta
ontology.template.yml + delta-pass.template.md
C3 P5 typology (5 categories · 56 types)
C4 Acceptance: ≥90% of entities have a type · all statements classified · CI/VI computed
ontology.yml
I3 Accumulated entities.csv + relations.csv
I4 tracks-grid.md — for track context
+ DELTA
ontology.yml
O2 Updated entities.csv + relations.csv
O3 delta.md broken down into 4 categories
O4 Typology-extension log (if User-Driven Schema Evolution was triggered)
ontology.yml · entities.csv · relations.csv · delta.md
Inner loop (per ambiguity): for disputed statements — the LLM asks a clarifying question of USR (or requests an additional source) — repeat Classify.
A5 · Synthesis and analytics
synthesis.template.md + competency-questions.template.md
C3 Acceptance: every synthesis statement → a reference to entities/relations; no "bare" generalizations
ontology.yml (current)
I2 entities.csv + relations.csv
I3 delta.md
I4 parameters.yml (for audience/format)
synthesis.md (with provenance for every wording)
O2 analytics.html (visual slices)
O3 Signal to A6 (launch CQ check)
synthesis.md · analytics.html
If after A6 (CQ validation) the answer rate is <80% — return here with clarifying questions.
The other 5 blocks · compact table in the same template
| Block | Inputs (main) | Controls | Mechanisms | Outputs · anchor |
|---|---|---|---|---|
| A2 Research plan | parameters.yml | METHOD §04 step 02; research-plan.template.md |
LLM decompose into questions · DET check frame coverage · USR approve | research-plan.md |
| A3 Tracks | research-plan.md | METHOD §04 step 03; tracks-grid.template.md |
LLM split into tracks · DET orthogonality check · USR owners | tracks-grid.md |
| A6 CQ validation | synthesis.md + parameters.yml | METHOD §04 step 05 (CQ tab); competency-questions.template.md |
LLM run questions over the synthesis text · DET count "answered / partial / no" · USR add own CQs | competency-questions.md |
| A7 Mirror | synthesis.md + 05_PROJECTS/INDEX.md | METHOD §04 step 06; mirror-map.template.md |
LLM project phenomena → projects · DET match by tags · USR refine "hit/partial/gap" | mirror-map.md |
| A8 Gap + publication | mirror-map.md + project state | METHOD §04 steps 07-08; gap-analysis.template.md + publish-brief.template.md |
LLM wording gaps + options · DET ranking · USR approve priorities · assemble the publish package | gap-analysis.md + publish/ |
The universal refinement loop
The same 5-beat pattern inside every block. Not free-form dialogue, but a formal sequence.
Loop rules
- A visible list of ALL questions v2. Before beat-2 starts, the LLM shows the whole scope of questions as one list — the user sees how many remain and which. This removes the "when will this end" anxiety and gives a sense of control over the process.
- One question per beat-2, not a batch. While keeping the overall list in view — ask one at a time, so each answer is deliberate. If there are nine parameters (6 base + 3 opt.) — nine sequential beat-2s.
- A draft-object, not a reply v2. At beat 3 the LLM creates
draft.<step>.mdas a file in the case. Agreement "in words in the chat" doesn't count; editing changes the file. - Confirm = rename v2. At beat 5, after an explicit "yes" from the user —
draft.<step>.md → final.<step>.md+ a quote of agreement intodecisions.log. Before the rename the file is a candidate, after — the run state. - Agreement is quoted in decisions.log. "Aleksei: yes, the ontology type is standard." This is an anchor that outlives the session.
- Commit is deterministic. The template validator runs automatically; if it fails — the loop is not considered closed.
- If beat-5 succeeds — move to the next block. If not — return to beat-2 with a note of exactly what didn't match.
"Let's discuss it in the chat now — I'll write it down later." This kills reproducibility. The right way: a draft file appears already at beat 3; agreement changes the file, it doesn't hang in an LLM reply.
Two visual indicators of the loop NEW v2
So the user sees progress and trusts the system, the loop is accompanied by two visualizations. Both are mandatory for skills, optional for a manual run.
Metaphor — the iPhone fingerprint: with each new answer, more areas of the template "light up". Implementation: a visual grid of the template's required fields (e.g., the 9 parameters of parameters.yml). A filled field — colored in the accent color, an empty one — gray. On top — a progress bar (3/9 · 33%). It's instantly clear what remains.
████████████░░░░░░░░ 55%
✓ topic ✓ horizon ✓ focus
✓ audience ✓ ontology type
☐ delta depth ☐ working_hypothesis
☐ key_questions ☐ custom_scoring
Style reference — Block-Zh-Talent-Migration-Map.html (Peace_Committee_AI_2026, D3.js force-directed, 333 nodes / 565 edges, multi-layer filtering, color semantics, hover tooltips). Adaptation: each node — an entity from entities.csv, each edge — from relations.csv. Change markers: green = NEW in the current pass, blue = CONFIRMED, orange = CONTRADICTION (not red!), gray = KNOWN. Side panel — filter by status / CI / cognitive type / tracks.
● 47 nodes (12 NEW · 28 CONFIRMED ·
5 CONTRADICTION · 2 KNOWN)
— 89 edges
Filters: [cogn.type ▾] [status ▾] [track ▾]
Tech: D3.js v7 force-simulation
Style source: /Peace_Committee/
Block-Zh-Talent-Migration-Map.html
The fill-rate metaphor — the Apple TouchID setup wizard (the fingerprint gradually "lighting up" with each touch).
The graph — /Cowork/Peace_Committee_AI_2026/2 - Block-Zh-Talent-Migration-Map.html (mirrored in cases/01-western-ai-ecosystem-2026-04/source/synthesis-and-analytics/). Self-contained tech: D3.js v7 + plain HTML/SVG, no dependencies beyond the CDN load of D3. Supports hover tooltips, drag, zoom/pan, a left filter panel, a right detail panel.
How to hold rigor across sessions
The LLM session is lost. Files are not. The pipeline is arranged so a new session can enter the middle of a run and continue without loss.
Twelve pillars of rigor (+2 new after v3.0)
parameters.yml · research-plan.md · tracks-grid.md · ontology.yml · synthesis.md · competency-questions.md · mirror-map.md · gap-analysis.md. This is the full set of state points. By the presence/absence of a file you can instantly tell which block the run is on.
In each cases/XX/ there is an INIT_MESSAGE.md with a ready prompt: "Read parameters.yml, ontology.yml, the latest artifact. Run state — N. Current task — ...". This makes a new session enter context in one step.
In each case folder — a decision log. Not "discussed verbally", but "date · block · quote of agreement". This is the anchor for cases where you need to quickly understand why a parameter is what it is. One or several short entries per closed beat-5 of the loop.
A complement to decisions.log, added as a result of Experiment-2 (FINDING #1). It contains EVERYTHING of the interaction: my questions (QUESTION), my drafts (DRAFT), technical observations (ANALYSIS), the user's answers (ANSWER), directives (DIRECTIVE), critiques and reframing (CRITIQUE), final agreements (CONFIRM), findings along the way (FINDING). Each entry: [timestamp · phase · actor · type] content. Without it: the context of "why it's this way and not another" is lost; meta-learning of the system is impossible; when reconciling statements against sources, the intermediate logic is lost.
Load split: decisions.log = "what was decided" (a fast answer), interaction.log = "how exactly we got there" (full context).
parameters.yml — a YAML schema (6 keys, an enum for "ontology type"). entities.csv — a column schema (id · type · name · source · created_at · CI). delta.md — presence of 4 sections. The validator runs at beat-5 of every loop. Without validation — the output is not considered committed.
When ontology.yml is updated — the old version is copied to archive/ontology-vN.yml. This makes it possible to roll back or compare how the understanding of the domain changed between runs.
In entities.csv and relations.csv each row has a source field (file path + quote/anchor inside). On discrepancies between sessions you can always return to the source and reconsider.
CI computation · template validation · building the adjacency graph · CQ coverage counting — deterministic functions. They don't depend on chat state. If the LLM in a new session "forgot" — DET re-runs on the current files and gives the same result.
In each row of entities.csv / relations.csv / delta.md a char-locator is stored: source_file + source_char_start + source_char_end. Click a statement in analytics.html / the graph → the exact fragment in the source raw_text is highlighted. Click a quote → the statements based on it are highlighted. This is not only UX convenience but a verification tool: the user instantly sees whether the LLM interpreted the fragment correctly. Without two-way verifiability, any LLM error in the extract phase is propagated through the whole downstream pipeline.
When extracting from several hubs (phase A4) each hub has its own ID prefix (ENT-NNN, ENT-MNN, ENT-PNN, ENT-INN, ENT-SNN, etc.). If a person/org is already in the graph under ENT-X — do not create a duplicate, use the existing ID in the new hub's relations. This creates cross-bridge edges automatically via graph topology. Duplication = false-negative cross-bridge counts (the graph will show 0 bridges where there are 10). See doctrine skills/ecosystem-extract-and-aggregate/doctrines/id-reuse-cross-bridges.md.
When checking a hypothesis like "X-nodes in Y-positions" — do not check via label string match (`hub_source.contains('X')` or ID prefix). Check via the actual graph structure: neighbors, shortest paths, intersections of edge sets. The bug pattern of the first CH-2 check iteration in exp-2: checked a metadata tag → a false-negative "PRELIMINARY" verdict. The refined check via neighborhood hub_sources gave 6/10 top-betweenness cross-bridges. See doctrine skills/ecosystem-extract-and-aggregate/doctrines/metadata-vs-graph-structure.md.
In v3.2 and earlier the method had inverted causality: the Q5 ontology was defined in A1 by a guess, BEFORE reconnaissance of the ecosystem. This locked thinking into a narrow box and missed whole classes of actors. v4.0/v3.0 fix: first A0 cartography (actors-map + dependencies-map + events-timeline) gives an inductive "map of the territory", and only then A1.5 synthesizes the formal ontology with an understanding of all the needed types. This is the same pattern as in the Block-Zh academic structure — there first a 1280×820 SVG map with 50+ named boxes, THEN a formal classification. See METHOD v4.0 §00 + §01b. Anti-pattern: defining Q5 in A1 by "guessing" — this always yields an incomplete ontology.
This pillar creates a cross-cutting feedback loop between the data layer and the schema layer:
- Trigger 1: the Extract phase discovered a new relation type → flag for
onto-extension v+1 - Trigger 2: reflect_block emerged_questions point to a missing entity type → propose an onto-extension
- Trigger 3: A5 contradictions Class 6 ONTOLOGY_GAPS surfaced entities not fitting Q5 → propose
- Action: onto-extensions are versioned (v8 → v9 → v10) with explicit rationale in
ontology-history.md
In v3.2 emerged extensions (was_juror_then_ambassador · patron_of · helped_found · 9 institutional archetypes) appeared after the fact without formalization. Pillar 12 prevents this: continuous feedback guarantees the ontology "breathes" with the data.
Run state = (the set of anchor files) + (decisions.log) + (deterministic indexes) + (char-locators to the source). The LLM session is working memory, it may change. Files and char-locators are long-term memory, they are invariant and verifiable. This triad gives the rigor you are looking for.
Experiment-1 · what to try right now
Don't build all 13 skills at once. Run the refinement loop on a single block, on familiar material, see how it holds — and only then lay down the rest.
What we take
- Material: the Western AI case · 2026-04 (
cases/01-western-ai-ecosystem-2026-04/source/). It's already familiar and exists as a reference. - Block: A1 (Run parameters). The simplest, the most illustrative for the refinement loop. After it — A4 (ontology+delta) on one small subset of the material.
- Skill: for now we write nothing new. We run it manually, by the 5-beat loop, through an ordinary chat. The goal — to feel the pattern and see the weak spots.
Experiment steps
- Prepare an "experiment-1" folder. Create
cases/exp-1-loop-test/with empty parameters.yml + decisions.log + INIT_MESSAGE.md (a ready "read and continue" prompt). - Run the A1 loop. 6 parameters in sequence (one per beat-2). Each agreement — a quote in decisions.log. At beat-5 — validate the YAML by hand (no script yet).
- Close the session. Open a new session. Paste the INIT_MESSAGE — see whether work begins "from where it left off", or is lost.
- Run the A4 loop on one source. Take one page from the Western AI materials. Run 4 beats (Scan → Extract → Classify → Gap-fill). Write into delta.md by the template.
- Checkout. Fill a short report in
cases/exp-1-loop-test/REPORT.md: what worked, what didn't, which edits are needed in the IDEF0 decomposition, which in the templates, which in the DET functions.
What we check
- Rigor of the refinement loop. Does "one question per beat" really hold focus, or is it too slow.
- Transition between sessions. Does INIT_MESSAGE work as a "context loader".
- The LLM vs DET demarcation. Is the boundary visible, does it blur in real work.
- Templates. Are the right fields in parameters.yml and delta.md; what to add/remove.
- Tempo. How much time one block actually takes, to estimate the effort of a full run.
What we do NOT do in experiment-1
- We don't build skills (not even the first wave).
- We don't write DET scripts for the validators (only check by eye).
- We don't synthesize over the full corpus — only over one source.
- We don't spend time on the beauty of artifacts — this is draft mode.
If the pattern holds — we lay down Wave 1 of the skills (ecosystem-init, ecosystem-ontology, ecosystem-extract-knowledge-delta, ecosystem-synthesis, ecosystem-validate-cqs) and write the first DET validators. If something falls apart — we reassemble the IDEF0 decomposition in the part that broke, before laying down the skills. This is the "one-two-three, one-two-three": a small run → an edit → the next run.