Claim skeleton: analyse an agentic system

Practical purpose

One public, user-invocable instruction must analyse one agentic system at one frozen evidence boundary; run a mandatory runtime baseline and only the applicable memory/context and epistemic lenses; reconcile shared records; and return one bounded system synthesis. Runtime and memory/context operations are embedded. The existing epistemic procedure is invoked conditionally. Physical result shape remains open, but the logical result contract does not. Basis: brief.md governing question, practical purpose, operativity, and fixed architecture; claim-disposition.md sections A–B.

Basis shorthand below: B = brief.md; R1/R2/R3/R4/R5/R6/R7 = corresponding reconstruction.md sections; DA/DB/DC/DE = corresponding claim-disposition.md sections.

Ordered plan for the public skill

1. Declare operativity and open one run

Work: establish who acts and what all later claims refer to.

• Imperative title “Analyse an Agentic System”; trigger on requests to analyse, review, or refresh an external agent runtime, harness, orchestration framework, agent operating layer, or narrower model-plus-machinery system. Consumer: analysing agent or maintainer. Channel: explicit invocation or trigger-matched loading. Force: prescriptive analysis and result-writing policy. Basis: B target/scope/operativity; DA.
• Accept a system identifier, source inputs, and optional output/staging identity. Allocate one run/result ID before analysis. Basis: B practical purpose; R6.13/R6.17; DA.
• Define the reviewed boundary by function: include components or actors whose scheduling, context selection, retained state, action execution, checking, acceptance, or authority decisions produce or constrain the behavior under review. List inclusions, exclusions, and external dependencies. A subsystem-only boundary must be named and cannot support whole-system conclusions. Basis: B audience/fixed architecture; R2; R6.1; DA.
• Early exit out of scope when the subject is not within B’s agentic-system scope. Treat inability to state a coherent system or subsystem boundary as blocking. Basis: B scope; R6.1.

2. Freeze sources once

Work: create one inspectable revision/capture boundary and evidence packet shared by all lenses.

• Branch by source kind: resolve an immutable revision for a repository reference; inspect an existing checkout without mutating it by default; preserve identity/version/fingerprint for a supplied snapshot or document bundle; capture a dated inspectable boundary for live or mixed documents where permitted. Record one analysis cutoff. Basis: B code/doc scope and one-boundary rule; R3.2; R6.2; DA.
• A dirty checkout is usable only when the exact inspected state can be identified and retained. A stable but old/partial boundary permits an explicit limitation; no stable inspectable boundary yields a blocker report, not a substantive analysis. Basis: R3.2; R6.2; DA.
• Build a canonical SRC-* register: kind, identity/location, revision/capture, evidence layer, inspected scope, anchors, and access gaps. Prepare the evidence packet once. Lens workers must not reacquire, refresh, or widen it. Targeted reads inside the frozen boundary are added centrally and invalidate affected downstream findings. Basis: B fixed architecture; R2/R3.2; R6.3/R6.12; DA.

3. Fix executable truth conditions and shared ownership

Work: prevent lenses from using the same words or objects differently.

Evidence

• Overall code-grounded requires inspection of implementation material to the central runtime account; otherwise use doc-grounded. Mixed gaps remain claim-local limitations. Per-source layers are implementation, doctrine/design, reported operation, observed run, and causal experiment. Basis: B distinctions; R1.1/R1.3/R3.2; R6.3; DA.
• Conclusion statuses:
• absent: not found inside a named, sufficiently inspected boundary;
• inapplicable: stated trigger conditions are false inside that boundary;
• uninspected: evidence needed to decide was unavailable or not inspected;
• claimed: doctrine or reported operation asserts it;
• implemented: inspected code affords it, without proving deployment;
• observed: a run exhibits it, without proving cause;
• causally supported: intervention/comparison plus design evidence supports attribution. Basis: B audience/distinctions; R1.1/R1.3; R6.3; DA.
• Every negative or uncertain result names the inspected boundary and exact conclusion prevented. Never upgrade context presence to activation, implementation to observed operation, observation to causality, or operational continuation to warrant. Basis: B acceptance; R1.2/R1.3; DA.

Definitions and records

• memory read-back: material accumulated or changed through use returns to a later invocation or action. Static shipped material and ordinary current-run state are retained state, not read-back. activation: evidence the delivered material changed behavior, not merely entered context. Basis: B distinctions; R1.2; DB.
• truth-apt: capable of truth or falsity. A material epistemic route produces/changes such content, checks/disposes it, changes its authority, retains/integrates it for reliance, or is required to assess a consequential knowledge/warrant claim. Operational curation names what a mechanism does to retained material; it does not establish semantic transformation or warrant. Basis: B distinctions; R1.3/R3.4; DB.
• behavioral authority is one consumption path’s consumer, channel, force, and horizon. epistemic authority licenses content/scope; operational authority licenses or blocks behavior. Keep all three separate. Basis: B distinctions; R1.2/R1.3; R6.11; DB.

Canonical record	Owner	Lens rule	Basis
SRC-* source	Orchestrator	cite; never replace boundary/layer	R2; R6.4; DA
CMP-* component, OBJ-* operative object	Orchestrator/runtime owns generic identity/form/substrate	lenses extend by ID	R2; R6.4; DA
RTE-* control/context/state/action route	Runtime owns common endpoints/progression	memory and epistemic lenses annotate or centrally register one new route	R2; R6.4/R6.9; DB
CLM-* claim	Orchestrator namespace	epistemic lens owns truth/scope/warrant fields	R1.3/R2; DA
BAP-* behavioral-authority path	Orchestrator	lenses reference; epistemic/operational authority remain lens-owned	R2; R6.11; DB

No lens may rename or independently inventory a registered object or route. New material records return to the orchestrator for one canonical ID. Basis: B stable-ID rule; R2; DA.

4. Run the finite runtime baseline

Work: explain ordinary control progression before optional lenses.

• Treat scheduling, context assembly, and external state/action as causal responsibilities, not mandatory modules. For each material loop record trigger/input, next-step owner, decision policy and form, context selection/framing, state read/write, action executor/boundary, persistence, coordination/return, retry/cancellation/recovery, and output; link all records by canonical IDs and evidence. Basis: B fixed architecture; R1.1; R6.5; DB.
• A filesystem is not a scheduler; retention is not context selection; a tool schema in context is not tool execution. Basis: R1.1; DB.
• Inspect permissions, governance, observability, providers, UI, packaging, performance, and other surfaces only when they alter the question, control path, evidence strength, or a lens result. State materiality. Do not turn the inventory into a universal taxonomy, fixed template, maturity ladder, ranking, or adoption advice. Basis: B scope/exclusions; R1.1/R5; DB.

5. Decide lens applicability

Work: make early exits explicit.

• Emit for each optional lens: {lens, applicable|inapplicable|uncertain, trigger evidence IDs, inspected boundary, rationale, action, prevented conclusions}. Applicable runs; inapplicable exits; uncertain exits as an explicit evidence limitation, never as absence. A candidate trigger means applicable, not uncertain. Basis: B fixed architecture/acceptance; R2; R6.8; DA.
• Memory/context: applicable when code, documentation, or observation identifies a path by which material accumulated or changed through use can affect a later invocation/action. Inapplicable requires sufficient evidence of no such path. Static shipped material, current-run state, or retained material with no later delivery path does not qualify. A claimed path triggers analysis; later status preserves claim versus implementation versus observation. Basis: B memory trigger/distinctions; R1.2; R6.6; DB.
• Epistemic: applicable when a material route handles truth-apt content or the system makes a consequential knowledge-production/warrant claim, even if the result is failure or absence. Successful knowledge production is not a prerequisite. Basis: B epistemic trigger/acceptance; R1.3/R3.5; R6.7; DB.
• Evaluated direct behavior or policy adaptation with no truth-apt object and no knowledge/warrant claim does not alone trigger the epistemic lens. Keep it in runtime. If another trigger applies, include that route in the invoked epistemic method. Basis: B scope; R3.5/R6.7; DB disposition decision.

6. Run the embedded memory/context lens

Work: analyse accumulated-from-use mechanisms, not the current memory-review publication lifecycle.

• Inventory retained operative parts, splitting bundles when content, form, producer/consumer, checks, or authority path differs. Record substrate, form, persistence, lineage, producer/consumer, invalidation/regeneration, and promotion toward stronger form/force. Basis: R1.2/R4; DB.
• Separate write from read-back: manual/automatic write; acquisition/index maintenance versus curation; applicable consolidation, deduplication, evolution, synthesis, invalidation, decay, promotion; raw trace versus distilled artifact where relevant. Basis: R1.2/R4; DB.
• Annotate the runtime-owned context route with pull/push/both, selection signal, targeting, scope/budget, delivery/consumption point, and faithfulness test. Post-turn capture remains write-side maintenance. Record context presence, deployed wiring, activation, and causal effect separately. Basis: R1.2/R2; R6.9; DB.
• Reference BAP-*; do not let authority-family labels replace consumer/channel/force/horizon. Keep lineage/curation independent of epistemic transformation, acceptance, and warrant. Basis: R3.4; R6.10/R6.11; DB.
• Omit checkout/archive/publication mechanics, Commonplace comparison, borrowable ideas, curiosity, watch items, and routing. Basis: B exclusions; R3.3/R4; DB/DC.

7. Invoke the epistemic procedure conditionally

Work: reuse the accepted method without giving it a second source or publication lifecycle.

• Invoke kb/instructions/analyse-external-system-epistemic-architecture.md; do not copy its object, route, transformation, lifecycle, claim-comparison, or authority method. Basis: R1.3/R3.5; DB.
• Pass a bounded epistemic subquestion, run/system boundary, frozen revision, SRC-* register/evidence packet, existing canonical records, and trigger evidence. Wrapper rules: no reacquisition, widening, revision change, silent evidence upgrade, parallel ID namespace, independent publication, or system-wide grade. Basis: B fixed architecture; R2/R3.5; DB.
• Require linked returns for material objects/routes/claims; transformation and route function; architectural and episode status; checking, acceptance, retention/integration; three authority records; and missing evidence/prevented conclusions. New records or targeted evidence requests return to the orchestrator for registration and affected-work rerun. Basis: R1.3/R2; R6.4/R6.12; DB.
• Fresh workers may consume only the prepared packet and frozen read-only boundary. If unavailable, execute sequentially. If neither path can run an applicable lens, stop with a capacity/dependency blocker; never relabel it inapplicable. Basis: B operativity; R6.12; DA.

8. Reconcile and synthesize

Work: produce one system account without flattening lens meanings.

• Merge duplicate objects/routes by ID; preserve anchored evidence conflicts; never select the strongest-sounding status. Runtime owns complete control/context routes; memory annotates read-back/activation; epistemic analysis annotates transformation, checking, warrant, acceptance, integration, and its authorities. Basis: B stable-ID/synthesis rules; R2; R6.9–R6.11; DA/DB.
• Check shared routes for one revision, sources, endpoints, objects, and BAP-*. Memory curation cannot determine epistemic transformation; behavioral influence cannot imply epistemic or operational authority. Basis: B distinctions; R3.4; DB.
• Organize synthesis around deployed progression: scheduling, context, state/action, memory return, truth-apt/warrant routes, and governing controls. Preserve capability/deployment and evidence-layer limits. State early exits only where they bound conclusions. Do not concatenate lens reports or assign a system-wide epistemic grade. Basis: B audience/fixed architecture; R1/R5; DA.

9. Emit the logical result

Work: require the same complete result whether one file, a package, or a structured response.

Required logical records, in order: run/staging identity; system boundary/revision/evidence tier; source register; shared component/object/route/claim/authority records; runtime account; both applicability records; applicable lens outputs or early exits; cross-lens reconciliation; bounded synthesis; limitations paired with prevented conclusions; verification/blocker report. Basis: B audience/known uncertainty; R2; R6.8/R6.13; DA/DE.

• Require one canonical result identity and resolvable IDs across physical parts. Do not decide one-file versus package layout in this target. Basis: B known uncertainty; R6.13; DA/DE.
• Publish only to an authorized target whose existing contract can represent the result. Otherwise retain the logical staging result and report a publication blocker; do not improvise a collection contract or reuse the memory schema. Basis: B exclusions; R3.3/R6.13/R6.16; DA/DC.

10. Verify and report

Work: separate a bounded result from an incomplete one.

• Verify source anchors/statuses, unique/resolving IDs, one boundary/revision, mandatory runtime coverage, both lens dispositions, all applicable outputs, prevented conclusions for non-runs, shared-route ownership, and absence of forbidden evidence upgrades. Basis: B acceptance; R6.3/R6.4/R6.8/R6.16; DA.
• Check specifically: retention ≠ read-back; context ≠ activation; implementation ≠ deployment; observation ≠ causality; curation ≠ warrant; use ≠ acceptance; behavioral authority ≠ epistemic/operational authority. Basis: B distinctions; R1.2/R1.3; DB.
• Run deterministic validation required by the chosen existing target contract. Until a dedicated result contract exists, use applicable generic validation plus this semantic checklist; do not change schemas/parsers to manufacture validation. Basis: R6.16; DC.
• Report result identity/location, boundary/revision/tier, lens dispositions, limitations, and blockers. Basis: B audience; DA.

Blockers, limitations, and unresolved-marker classification

Marker/condition	Classification	Resolution or handling
R6.1 boundary	Blocking if unresolved	Section 1 defines it; otherwise stop.
R6.2 acquisition/freshness	Split: no stable boundary is blocking; exact source mechanics are omittable; stable partial freshness is a published limitation	Section 2 branches by source kind.
R6.3 evidence model	Blocking if unresolved	Section 3 defines tier/layer/status.
R6.4 canonical records	Blocking if unresolved	Section 3 fixes IDs/ownership.
R6.5 runtime baseline	Blocking if unresolved	Section 4 supplies finite core/materiality.
R6.6 memory applicability	Blocking if unresolved	Section 5 fixes trigger/status.
R6.7 epistemic applicability	Blocking if unresolved	Section 5 fixes trigger and direct-adaptation exception.
R6.8 applicability output	Blocking if unresolved	Section 5 fixes record/early exit.
R6.9 context/activation owner	Blocking if unresolved	Runtime owns; memory annotates.
R6.10 lineage/transformation	Blocking if unresolved	Separate axes in sections 3/6.
R6.11 authority	Blocking if unresolved	Shared BAP-*; lens-owned licenses.
R6.12 worker topology	Blocking only if no worker or sequential path can run an applicable lens	Sections 2/7 fix packet and fallback.
R6.13 physical output	Explicit instruction-design limitation	Section 9 fixes logical contract only.
R6.14 editorial material	Omittable	Exclude.
R6.15 replacement lifecycle	Omittable	Exclude migration/archive/index work.
R6.16 verification	Blocking if omitted/failed	Section 10 supplies checks.
R6.17 operativity	Blocking if unresolved	Section 1 and metadata plan fix it.
R6.18 integrated trials	Blocking for promotion, not drafting	Cold-run four cases below.

Other publishable limitations: doc-only evidence, inaccessible components, no observed run, no causal experiment, unresolved applicability, and conflicting evidence—each must name its scope and prevented conclusion. Other publication blockers: missing logical records, ID collisions, unsupported material claims, failed applicable validation, or no authorized target contract. Basis: B acceptance; DA/DC.

No marker blocks Step 7 drafting. Before promotion, cold-run the exact candidate on: runtime only; runtime plus memory/no epistemic trigger; runtime plus epistemic; runtime plus both. Each must preserve one source register, stable IDs, explicit early exits, direct-adaptation trigger behavior, no evidence upgrade, logical completeness, and bounded synthesis. Basis: B acceptance; R6.18; DE.

Tempting branches to omit

• Product ranking, adoption advice, universal taxonomy/maturity ladder, or mandatory fixed-axis inventory. Basis: B exclusions; R5; DA.
• Separate runtime/memory instruction promotion or copied epistemic procedure. Basis: B target; DB/DC.
• Memory editorial/publication sections and checkout/archive mechanics. Basis: B exclusions; R3.3/R4; DB.
• New result type/schema/parser/matrix, memory-schema reuse, or repair of the trace-learning/trace-derived defect. Basis: B exclusions; R3.4; DC.
• Collection changes, corpus relocation/retrofit, review replacement, and index maintenance. Basis: B exclusions; R3.1/R3.3; DC.
• Source-specific commands, collision rules, trial-domain values, and current navigation details. Basis: R7; DE.