Claim disposition: analyse an agentic system
Source-first disposition
The target is an instruction with one practical purpose: orchestrate one system-first analysis against one pinned evidence boundary, applying runtime, memory/context, and epistemic analysis at their proper scopes and producing one bounded synthesis. A targeted title/description search found no existing public instruction that performs this combined job. The existing memory-review skill is a GitHub-specific publication workflow, while the existing epistemic instruction is an adequate analytical subprocedure but not a whole-system orchestrator.
A. Single public orchestrating instruction
| Candidate claim or requirement | Relation to the user target | Evidence basis | Existing artifact adequate? | Disposition | Target path | Why this boundary is useful |
|---|---|---|---|---|---|---|
| One user-invocable, system-first instruction must own the reviewed system, analysis run, conditional lenses, reconciliation, and final synthesis. | This is the target's single practical purpose. | User direction and intended practical purpose in brief.md; reconstruction stance and shared-concern table in reconstruction.md. |
No; title/description search found only the narrower memory-review and epistemic procedures. | central contribution |
kb/instructions/analyse-agentic-system/SKILL.md |
One entry point prevents the historical collection split from becoming execution architecture and gives the complete run one revision boundary and owner. |
| The instruction must be a discoverable skill whose consumer is an analysing agent or maintainer, whose channel is explicit invocation or trigger-matched skill loading, and whose force is prescriptive. | Makes the requested public entry point operative rather than inert. | Operativity fixed in brief.md; kb/instructions/COLLECTION.md; kb/types/instruction.md. |
The collection and type contracts state the rule, but no target skill realizes this path. | central contribution |
kb/instructions/analyse-agentic-system/SKILL.md |
Keeping routing and execution policy on the one public skill avoids separately discoverable lens entry points that could recreate fragmented reviews. |
| Before analysis, the workflow must declare the system boundary, included and excluded components, source identities, reviewed revision or version, overall evidence tier, and one canonical evidence register. | Supplies the common factual boundary every lens consumes. | Fixed analytical architecture and required distinctions in brief.md; sections 2, 3.1, and open questions 1–3 in reconstruction.md. |
Partly; kb/instructions/analyse-external-system-epistemic-architecture.md has a strong source-and-claim boundary, and the memory skill pins a checkout, but neither owns a combined run. |
central contribution |
kb/instructions/analyse-agentic-system/SKILL.md |
The shared declaration is revised once and prevents lens conclusions from silently referring to different systems, revisions, or source tiers. |
| Source preparation must branch by supplied source kind, freeze an inspectable identity before analysis, forbid lens workers from refreshing or widening it, and return an evidence-limited result when no stable boundary can be established. | Makes “inspect once at one pinned boundary” executable without assuming every source is a GitHub repository. | Scope and exclusions in brief.md; source-preparation conflicts and open question 2 in reconstruction.md. |
Partly; kb/instructions/write-agent-memory-system-review/SKILL.md handles GitHub checkout refresh, while kb/instructions/analyse-external-system-epistemic-architecture.md handles an already-established source boundary. |
central contribution |
kb/instructions/analyse-agentic-system/SKILL.md |
A source-kind branch belongs above all lenses; keeping fetch mechanics conditional avoids baking the current memory skill's GitHub-only policy into analysis semantics. |
| The workflow must distinguish overall code-grounded or doc-grounded scope, per-source implementation/doctrine/reported-operation/observed-run/causal-experiment layers, and conclusion-level absent/inapplicable/uninspected/claimed/implemented/observed/causally-supported statuses without upgrading among them. | Implements the required evidence vocabulary and negative findings. | Required distinctions and audience update in brief.md; sections 1.1, 1.3, 3.2, and open question 3 in reconstruction.md. |
Partly; the epistemic instruction adequately defines per-source layers, while the memory contract supplies artifact-level source tier, but no shared mapping exists. | central contribution |
kb/instructions/analyse-agentic-system/SKILL.md |
One mapping lets lenses share evidence while preserving the different questions answered by source tier, architectural status, observation, and causal support. |
| Every scoped absence, inapplicability, or uncertainty must name the inspected boundary and the exact conclusion it prevents. | Prevents empty lens output or missing evidence from masquerading as a negative system claim. | Audience update, fixed architecture, and acceptance criteria in brief.md; epistemic evidence rules and open questions 3 and 8 in reconstruction.md. |
The epistemic instruction states this adequately for its own route boundary, but no whole-system instruction applies it to all lenses. | central contribution |
kb/instructions/analyse-agentic-system/SKILL.md |
The negative record remains independently revisable when new evidence expands the boundary. |
| The public workflow must assign canonical source, component or object, route, claim, and behavioral-authority-path IDs, with lenses extending rather than renaming or re-inventorying shared records. | Realizes the user's stable-ID reconciliation requirement. | Fixed architecture item 6 in brief.md; shared-concern table and open question 4 in reconstruction.md. |
No; the epistemic procedure has source/object/route/claim IDs, while memory review content has no compatible shared record. | central contribution |
kb/instructions/analyse-agentic-system/SKILL.md |
Canonical IDs let the same retained object, context route, or authority path support several analytical views without duplicate facts drifting apart. |
The public workflow must record applicable, inapplicable, or uncertain for each optional lens, cite the evidence for that disposition, and state the conclusions prevented when the lens does not run. |
Makes conditional execution and early exit explicit. | Fixed architecture items 3–5 and acceptance criteria in brief.md; shared-concern table and open question 8 in reconstruction.md. |
No current whole-system example or instruction records both lens dispositions. | central contribution |
kb/instructions/analyse-agentic-system/SKILL.md |
Applicability is a routing result owned by the whole analysis, not an inference readers must make from an absent file or section. |
| Lens work may run in fresh worker contexts, but every worker must receive the same read-only boundary and prepared evidence register, may add only anchored findings within it, and must return to the orchestrator for reconciliation. | Preserves one source inspection and revision while permitting bounded specialist contexts. | Operativity and fixed architecture in brief.md; source-duplication conflict and open question 12 in reconstruction.md. |
No; the memory skill delegates source-grounded drafting but permits duplicate reading, and the epistemic instruction has no worker protocol. | central contribution |
kb/instructions/analyse-agentic-system/SKILL.md |
Worker topology is execution policy of the public workflow, not a semantic property of memory or epistemic analysis. |
| If fresh workers are unavailable, the workflow must either execute the applicable lens sequentially against the same register or stop with an explicit capacity blocker, never silently drop the lens or widen the evidence boundary. | Closes an execution branch required for first-reading operativity. | kb/instructions/COLLECTION.md; open question 12 in reconstruction.md; the memory skill's explicit no-worker stop is a narrower precedent. |
No combined fallback exists. | central contribution |
kb/instructions/analyse-agentic-system/SKILL.md |
The fallback choice is local execution policy and does not justify a separate lens artifact or a different analytical standard. |
| The final synthesis must organize around the deployed system and its control, context, state, action, memory, and warrant routes rather than concatenate lens reports or issue a system-wide epistemic grade. | Defines the requested reader update and completion result. | Intended practical purpose and fixed architecture item 7 in brief.md; sections 1.3 and 5 in reconstruction.md. |
Partly; the comparative precedent integrates salient axes, and the epistemic instruction forbids a system-wide grade, but no single-system orchestrator combines them. | central contribution |
kb/instructions/analyse-agentic-system/SKILL.md |
The synthesis can be revised as a whole-system account while lens records retain their own evidence and authority limits. |
| The public instruction must define one logical result contract—boundary, evidence register, runtime account, lens dispositions and outputs, reconciliation, bounded synthesis, and verification—without yet fixing one-file versus per-system-package persistence. | Makes the workflow testable while honoring the explicitly deferred publication choice. | Known uncertainties and acceptance criteria in brief.md; no-uniform-output finding and open question 13 in reconstruction.md; kb/types/instruction.md rule to leave live choices to the executor. |
No uniform whole-system output contract exists. | central contribution |
kb/instructions/analyse-agentic-system/SKILL.md |
Logical completeness can be tested independently of a physical layout that may later need a collection-owned type, schema, or parser. |
| Each invocation must record its chosen output or staging identity before writing and must not publish into a collection whose contract cannot represent the result. | Preserves artifact identity while physical publication remains under trial. | Public-workflow ownership and output-shape uncertainty in brief.md; contract mismatch in section 3.3 of reconstruction.md. |
No current procedure covers this provisional whole-system case. | central contribution |
kb/instructions/analyse-agentic-system/SKILL.md |
Per-run identity is necessary for reconciliation; permanent corpus layout is a separate collection-design decision. |
| The workflow must exclude product ranking, generic adoption advice, a universal maturity taxonomy, and claims beyond the declared evidence boundary. | Bounds the one practical purpose. | Scope and required distinctions in brief.md; “not established or generalizable” in section 5 of reconstruction.md. |
The runtime and epistemic artifacts each state parts of this boundary adequately. | support/example/scope only |
kb/instructions/analyse-agentic-system/SKILL.md |
These exclusions constrain execution without becoming independent contributions or new theory. |
B. Lens text and cross-lens ownership
For this run, the runtime and memory/context procedures are embedded in the one public skill because no library instruction is an adequate modular lens and the user did not authorize additional promotion targets. The epistemic procedure is invoked conditionally because kb/instructions/analyse-external-system-epistemic-architecture.md already provides an accepted, independently executable route analysis. All executor-facing trigger and reconciliation rules remain in the public skill.
| Candidate claim or requirement | Relation to the user target | Evidence basis | Existing artifact adequate? | Disposition | Target path | Why this boundary is useful |
|---|---|---|---|---|---|---|
| Every run must embed a finite runtime baseline that identifies scheduling, context assembly, and external state/action responsibilities and traces ordinary control progression across them. | Supplies the mandatory whole-system lens. | Fixed architecture item 2 in brief.md; section 1.1 and open question 5 in reconstruction.md. |
The theory in kb/notes/agent-runtime-analysis-should-separate-scheduling-context-state.md is adequate, but no executable runtime-analysis instruction exists. |
central contribution |
kb/instructions/analyse-agentic-system/SKILL.md |
Embedding the operational questions keeps the skill executable without turning a diagnostic theory note into a subprocedure. |
| The runtime baseline must inspect coordination, permissions, recovery, observability, governance, providers, user interfaces, packaging, and performance only when they materially affect the system question, control path, evidence strength, or lens result. | Prevents both omission of salient machinery and a false universal taxonomy. | Scope in brief.md; bounded comparison precedent and section 5 in reconstruction.md. |
The theory and precedent support the salience rule, but no reusable instruction states it. | central contribution |
kb/instructions/analyse-agentic-system/SKILL.md |
A materiality branch keeps the runtime core finite while allowing heterogeneous systems to expose different consequential surfaces. |
| The memory/context lens applies when material accumulated or changed through use can affect a later invocation or action; static shipped material, ordinary current-run state, no evidenced read-back, and unknown read-back must remain distinct. | Defines when the required conditional memory analysis runs. | Fixed architecture item 4 and retained-state distinction in brief.md; sections 1.2 and open question 6 in reconstruction.md. |
kb/notes/knowledge-storage-does-not-imply-contextual-activation.md states the distinctions adequately, but the current memory skill does not expose this applicability branch. |
central contribution |
kb/instructions/analyse-agentic-system/SKILL.md |
The trigger belongs in the orchestrator, while the durable conceptual distinction remains independently citable. |
| When applicable, the embedded memory/context lens must analyse retained operative parts, storage substrate and form, lineage, write and maintenance operations, retrieval/read-back direction and selection, context budget, activation evidence, capability versus deployment, and behavioral-authority paths. | Supplies the reusable analytical core of the current memory review without its publication workflow. | Section 1.2 and section 4 in reconstruction.md; established current memory procedure summarized there. |
Partly; the current memory type contains the analytical fields, but kb/instructions/write-agent-memory-system-review/SKILL.md couples them to GitHub checkout, collection publication, editorial sections, and QA. |
central contribution |
kb/instructions/analyse-agentic-system/SKILL.md |
Embedding only the analytical core prevents the existing memory publication lifecycle from becoming a nested workflow and avoids a forbidden execution dependency on another collection's type. |
| The runtime record must own the complete context-assembly route, while the memory lens annotates the accumulated-from-use subset, its selection signal, read-back direction, and any observed context-to-action activation. | Reconciles the principal overlap between runtime and memory analysis. | Shared-concern table and open question 9 in reconstruction.md; required storage/context/activation distinction in brief.md. |
No existing artifact specifies shared ownership, although the two theory notes establish the two sides. | central contribution |
kb/instructions/analyse-agentic-system/SKILL.md |
One route with lens annotations avoids duplicate context ledgers and keeps activation evidence from being upgraded from mere presence. |
| Memory write-side curation labels and retained-artifact lineage must remain separate from epistemic transformation class and warrant. | Prevents operational labels such as consolidation, synthesis, or import from silently licensing semantic preservation, entailment, or knowledge production. | Required content-curation distinction in brief.md; section 3.4 and open question 10 in reconstruction.md. |
The memory and epistemic artifacts define their own axes, but no crosswalk exists. | central contribution |
kb/instructions/analyse-agentic-system/SKILL.md |
Separate linked fields let each vocabulary evolve without changing the meaning of the other. |
| The shared authority record must name consumer, channel, force, and horizon, while epistemic authority and operational authority remain separate lens-owned licenses. | Prevents several meanings of authority from collapsing in synthesis. | Required distinctions in brief.md; sections 1.2, 1.3, 2, and open question 11 in reconstruction.md. |
kb/notes/definitions/behavioral-authority.md adequately states consumer/channel/force; the epistemic instruction adequately separates the other authorities; no canonical combined record exists. |
central contribution |
kb/instructions/analyse-agentic-system/SKILL.md |
One behavioral path can be referenced across lenses while epistemic and operational permissions remain independently revisable. |
| The epistemic lens must run when a material route handles truth-apt content or the system makes a consequential knowledge-production or warrant claim, even when the eventual finding is absence or failure. | Implements the user's conditional epistemic-analysis requirement without circularly requiring successful knowledge production first. | Fixed architecture item 5 and acceptance criteria in brief.md; section 3.5 and open question 7 in reconstruction.md. |
The existing epistemic instruction has the necessary material-route method, but its trigger is a direct epistemic question rather than a whole-system applicability decision. | central contribution |
kb/instructions/analyse-agentic-system/SKILL.md |
The orchestrator owns the applicability decision; the invoked method owns the route analysis after that decision. |
| Evaluated direct behavior or policy adaptation with no truth-apt object and no knowledge or warrant claim does not by itself trigger the epistemic lens, but it remains a runtime finding and is included by the epistemic method whenever another trigger makes that lens applicable. | Resolves the reconstruction ambiguity without broadening the user-specified trigger. | The fixed trigger and direct-policy scope in brief.md; section 3.5 and open question 7 in reconstruction.md; material-route boundary in the existing epistemic instruction. |
Partly; the epistemic instruction covers such routes once invoked, while no whole-system trigger rule states this branch. | support/example/scope only |
kb/instructions/analyse-agentic-system/SKILL.md |
This keeps non-epistemic adaptation visible without recategorizing every evaluated controller update as knowledge production. |
| Once applicable, the orchestrator should invoke the existing epistemic instruction in a bounded context rather than restate its object inventory, route ledger, transformation, lifecycle, claim-comparison, and authority rules. | Reuses the accepted epistemic lens inside the singular public workflow. | Existing-instruction assessment in reconstruction.md sections 1.3 and 3.5; permitted invokes context transfer in kb/instructions/COLLECTION.md. |
Yes; kb/instructions/analyse-external-system-epistemic-architecture.md is adequate for the analytical lens and has accepted cold-trial support, subject to wrapper constraints. |
cite existing |
kb/instructions/analyse-external-system-epistemic-architecture.md |
The epistemic method has an independent citation and revision boundary; invocation avoids a divergent copied method inside the orchestrator. |
| The epistemic invocation must reuse the orchestrator's system boundary, source IDs, component/object IDs, and evidence layers, return linked lens records, and must not perform fresh source acquisition or issue an independent publication decision. | Adapts the adequate standalone method to the combined workflow. | Fixed architecture items 1 and 6 in brief.md; shared-concern table and standalone-versus-embedded mismatch in reconstruction.md. |
No; the existing epistemic instruction establishes its own output-1 boundary because it currently runs standalone. | central contribution |
kb/instructions/analyse-agentic-system/SKILL.md |
The wrapper contract preserves the epistemic method while preventing duplicated source reading, renamed objects, and a second artifact lifecycle. |
| Commonplace comparison, borrowable ideas, curiosity, watch items, collection routing, and memory-review publication mechanics must not be part of the memory lens or mandatory whole-system analysis. | Removes historical editorial and production coupling from the analytical lens. | Exclusions and workshop-baseline direction in brief.md; sections 3.3, 4, and open question 14 in reconstruction.md. |
These are required by the current memory review type or skill, not by an adequate modular analysis. | omit/retain in workshop |
None for this target. | Editorial follow-up can later consume a completed system analysis without changing the truth conditions or completion criteria of the analytical workflow. |
C. Collection, type, schema, parser, and corpus boundaries
| Candidate claim or requirement | Relation to the user target | Evidence basis | Existing artifact adequate? | Disposition | Target path | Why this boundary is useful |
|---|---|---|---|---|---|---|
| The target should use the existing instruction collection and instruction type contracts without changing either contract. | Fixes the target's authoring and operativity shape. | Target and collection/type constraints in brief.md; kb/instructions/COLLECTION.md; kb/types/instruction.md. |
Yes; both contracts already admit a promoted, user-invocable skill with explicit scope, decisions, and verification. | cite existing |
kb/instructions/COLLECTION.md; kb/types/instruction.md |
Contract reuse keeps the run about the new workflow rather than an unrelated type-system change. |
| The agentic-systems collection's current “everything else” carve-out conflicts with the user-directed crosscutting-lens model, but its contract must not be revised before the workflow is tested. | Records a real future alignment need without expanding the current target. | Explicit exclusion in brief.md; section 3.1 in reconstruction.md. |
No; kb/agentic-systems/COLLECTION.md encodes the old split. |
omit/retain in workshop |
Potential later fold into kb/agentic-systems/COLLECTION.md, only after authorization and trials. |
Collection policy governs the whole corpus and should change only after the proposed workflow demonstrates a viable result shape. |
| A dedicated whole-system result type, schema, validator/parser support, and comparison-matrix integration must wait until trials establish the physical output shape and stable fields. | Separates the executable analysis method from premature codification. | Explicit exclusions and one-file/package uncertainty in brief.md; section 3.3 and open questions 13 and 16 in reconstruction.md. |
No current whole-system type or schema exists; the memory schema is too specialized. | omit/retain in workshop |
No path in this run; future collection-owned type/schema/parser paths after separate authorization. | Deferral allows the logical contract to change cheaply during trials and prevents an untested provisional layout from gaining deterministic force. |
| The memory collection, memory review type, memory schema, and systems-matrix parser must not be changed merely to accommodate the new orchestrator. | Enforces the user's no-retrofit boundary. | Explicit exclusions in brief.md; contract mismatch and machine-readable comparison analysis in reconstruction.md sections 3.3 and 4. |
Existing artifacts remain adequate for the current memory-review corpus, but not as the new whole-system result contract. | omit/retain in workshop |
kb/agent-memory-systems/COLLECTION.md; kb/agent-memory-systems/types/agent-memory-system-review.md; related schema/parser, only in a later authorized run. |
Existing typed reviews can remain stable while the new workflow is tested independently. |
The live memory type/schema trace-learning versus legacy trace-derived mismatch is an independent defect and must not be repaired in this instruction run. |
Prevents opportunistic unrelated schema work. | Section 3.4 of reconstruction.md; target exclusions in brief.md. |
No; the mismatch remains, but it does not block defining the orchestrator's practical purpose. | omit/retain in workshop |
Potential later repair of kb/agent-memory-systems/types/agent-memory-system-review.schema.yaml. |
A separate repair can be validated against the existing corpus without coupling it to a new analysis workflow. |
| The experimental runtime and memory/context workshop baselines must not be promoted as independent public instructions in this run. | Preserves the single public entry point and current authorization boundary. | Target statement and workshop-baseline direction in brief.md. |
No adequate public runtime or memory lens exists yet; the workshop copies are trial inputs, not library artifacts. | omit/retain in workshop |
None in this run; extraction may be reconsidered after successful trials. | Embedding now avoids creating additional artifacts before reuse, stability, and independent invocation value are demonstrated. |
| Existing agentic-system analyses and memory reviews must not be relocated, semantically retrofitted, or silently superseded by this new instruction. | Enforces the explicit no-corpus-migration scope. | Exclusions in brief.md; section 3.1 and open question 15 in reconstruction.md. |
Existing corpus artifacts describe their own pinned boundaries but do not form one unified corpus shape. | omit/retain in workshop |
No corpus target in this run. | Migration changes artifact identity, links, comparison data, and evidence boundaries and therefore needs a separate authorized plan after the new shape is proven. |
| Refresh, archive, replacement, and index-update behavior for prior reviews must remain outside the analytical lens and outside this new-write run. | Prevents the current memory publication lifecycle from controlling whole-system analysis. | Exclusions in brief.md; sections 3.3, 4, and open question 15 in reconstruction.md. |
kb/instructions/write-agent-memory-system-review/SKILL.md adequately specifies the old memory-specific lifecycle, not a future whole-system lifecycle. |
omit/retain in workshop |
No target until publication shape and migration policy are separately authorized. | Analysis semantics can stabilize before destructive or corpus-wide lifecycle behavior is chosen. |
D. Transferable theory already present
| Candidate durable claim | Relation to the user target | Evidence basis | Existing artifact adequate? | Disposition | Target path | Why this boundary is useful |
|---|---|---|---|---|---|---|
| Agent-runtime analysis should separate scheduling, context assembly, and external state/action responsibilities without treating them as mandatory module boundaries or an exhaustive taxonomy. | Grounds the embedded runtime baseline. | Section 1.1 of reconstruction.md; inspected library note. |
Yes. | cite existing |
kb/notes/agent-runtime-analysis-should-separate-scheduling-context-state.md |
The theory remains citable and revisable independently; the instruction should inline only its executable questions. |
| Agent orchestration occupies an open multi-dimensional design space rather than a single ladder. | Bounds the runtime reading inventory and prevents maturity scoring. | Section 1.1 and section 5 of reconstruction.md; inspected library note. |
Yes. | cite existing |
kb/notes/agent-orchestration-occupies-a-multi-dimensional-design-space.md |
A separate theory note can evolve the dimensions without turning the instruction into a fixed taxonomy. |
| Runtime governance is crosscutting, while runtime structure determines the preventive and reactive control surfaces governance can use. | Grounds conditional inspection of permission, recovery, observability, validation, and drift controls. | Section 1.1 and shared-concern table in reconstruction.md; inspected library note. |
Yes. | cite existing |
kb/notes/runtime-structure-determines-governance-control-surfaces.md |
The instruction can ask operational questions without carrying the full governance argument. |
| Agent memory is a crosscutting view of storage, retrieval/activation, and learning-from-use rather than a fourth peer runtime component. | Grounds the user's correction that memory belongs inside system analysis when applicable. | User direction in brief.md; section 1.2 of reconstruction.md; inspected library note. |
Yes. | cite existing |
kb/notes/agent-memory-is-a-crosscutting-concern-not-a-separable-niche.md |
Keeping the theory separate avoids restating a settled claim as if the new skill originated it. |
| Retention, memory read-back, context presence, and contextual activation are distinct states with different evidence requirements. | Grounds the memory trigger, shared context record, and evidence limits. | Required distinctions in brief.md; section 1.2 of reconstruction.md; inspected library note. |
Yes. | cite existing |
kb/notes/knowledge-storage-does-not-imply-contextual-activation.md |
The durable distinction can support other procedures while this skill operationalizes only the decisions it needs. |
| Behavioral authority belongs to a consumption path and records consumer, channel, and force rather than inhering in stored bytes. | Grounds the canonical cross-lens authority record. | Required distinctions in brief.md; sections 1.2 and 2 of reconstruction.md; inspected definition. |
Yes. | cite existing |
kb/notes/definitions/behavioral-authority.md |
The definition remains the vocabulary authority while the skill adds run-specific IDs and horizon. |
| Skills add structured discovery, direct invocation, and execution policy to an instruction body. | Grounds use of one promoted public skill rather than an inert plain procedure. | Operativity in brief.md; kb/types/instruction.md; inspected theory note. |
Yes. | cite existing |
kb/notes/skills-are-instructions-plus-routing-and-execution-policy.md |
Packaging theory remains separate from the concrete trigger and execution policy chosen for this skill. |
| Frontloading removes already-known setup work from a consuming context, while invoking an independent procedure is useful when it preserves a stable callable boundary rather than merely shifting required reading. | Informs the embed/invoke boundary among lenses. | Frontloading requirement in kb/instructions/COLLECTION.md; inspected kb/notes/frontloading-spares-execution-context.md and kb/notes/model-resolved-indirection-adds-interpretation-work-to-llm-execution.md; lens adequacy findings in reconstruction.md. |
Yes, as general theory. | cite existing |
kb/notes/frontloading-spares-execution-context.md; kb/notes/model-resolved-indirection-adds-interpretation-work-to-llm-execution.md |
The skill may embed the missing runtime/memory operations and invoke the stable epistemic callable without presenting that packaging choice as new theory. |
E. Support, trials, and intentionally deferred choices
| Candidate claim or requirement | Relation to the user target | Evidence basis | Existing artifact adequate? | Disposition | Target path | Why this boundary is useful |
|---|---|---|---|---|---|---|
| Before promotion, cold executions must cover runtime-only, runtime plus memory without material epistemic transformation, runtime plus epistemic routes, and runtime plus both lenses. | Supplies acceptance evidence for the instruction rather than a step in every future analysis. | Acceptance criteria in brief.md; open question 18 in reconstruction.md. |
No integrated cold trials exist; prior trials cover only the standalone epistemic procedure. | support/example/scope only |
Later workshop trial and acceptance artifacts for this run. | Trial evidence should test the instruction without becoming permanent executor-facing procedure text. |
| Current Agno, Claude Code workflow, Exo, and GBrain analyses demonstrate heterogeneous runtime surfaces and useful epistemic questions but do not establish a uniform output contract or integrated execution. | Supports salience and scope decisions. | Section 5 of reconstruction.md. |
Yes as examples, not as a reusable method. | support/example/scope only |
Existing kb/agentic-systems/ analyses. |
Examples test coverage without becoming mandatory sections or universal categories. |
| Exact checkout collision rules, archive suffixes, command spellings, source-specific identifiers, trial-domain values, and current navigation order are irrelevant to the public analytical purpose. | Keeps concrete source residue out of the target. | Section 7 of reconstruction.md. |
Existing source procedures remain authoritative in their own scopes. | omit/retain in workshop |
None for this target. | Omitting mechanics that do not affect the governing question preserves a small, reusable instruction boundary. |
| One-file versus package publication remains intentionally deferred until trials, so this run should require a complete logical result and per-run staging identity without selecting a permanent corpus shape. | Preserves the explicitly open design choice without blocking the fixed public instruction. | Known uncertainties in brief.md; section 5 and open question 13 in reconstruction.md. |
No existing contract resolves the physical shape. | omit/retain in workshop |
Future collection/type design after trial evidence. | The choice changes collection and schema commitments, not the current skill's singular practical purpose. |
Decision status
No DECISION NEEDED marker is warranted at this stage. The user direction fixes the target identity, singular public entry point, and system-first practical purpose. It also withholds authorization for independent runtime or memory-lens promotion, schema/parser changes, and corpus migration until the workflow is tested. The remaining source-acquisition and worker-topology variations are executable runtime branches, while physical publication shape is explicitly deferred behind trials rather than left as an unresolved choice the current target must make.
The integrated cold trials remain evidence needed before promotion, but they do not block Step 6 from planning the instruction against the fixed logical result contract.