Source-linked AI summary
Progressive Skill Discovery as Access Control for Tool-Using LLM Agents: Structural Governance through Role-Scoped Capability Delivery
Michael Stettler, Benjamin Girardet, Jonas Canton, Nicolas Corod
TL;DR
Large tool catalogs make tool selection and governance difficult, and prompt instructions alone do not enforce access boundaries. Skilder delivers skills and tools through progressively learned roles and a single MCP server. In the evaluation, the simulated authorization layer blocked forbidden governed calls, while end-to-end outcomes also depended on whether models completed discovery and response checks.
Problem
Method
Skilder packages skills, tools, instructions, and limits into roles that agents learn progressively through one MCP server, which executes tools only from learned skills.
Source: §3 · p. 3Results
The simulated authorization layer observed no forbidden action executing after a governed call reached it, while end-to-end pass rates also reflected discovery and response-quality checks.
Source: §4.1 · p. 4Takeaways & Limitations
Agents can learn additional roles when tasks cross domains, while the router blocks tools outside learned roles.
Source: Does adaptability undermine governance? · p. 13The authorization results measure a simulated role design rather than a live runtime, and some models struggled with progressive discovery and nested tool-call arguments.
Source: §6.3 · p. 17
Abstract
from arXiv · showhide
Large Language Model (LLM) agents struggle to scale safely when exposed to vast enterprise toolsets. Providing an agent with access to every internal tool leads to oversized context windows, degraded tool selection, and severe governance vulnerabilities - as system policies defined purely in prompts remain probabilistic advice rather than hard constraints. Existing mitigations, such as multi-agent domain delegation, decentralize audit logs and fail to guarantee policy compliance across sessions. We introduce skilder, a framework that packages capabilities into roles: bundles of skills, tools, and instructions, together with the limits that bound them. An agent begins with a minimal role catalog, learns the roles a task requires, and receives each role's skills, instructions, and tools through a single MCP server. Because tools reach the agent only inside learned skills, the same server enforces the scope of what was learned deterministically. We evaluate skilder against flat-context tool selection and multi-agent orchestration across 13 tasks using six models (10 runs each). Our results show that, when models completed discovery and issued a governed call, the skilder simulated authorization layer enforced governance boundaries: no unauthorized tool call or parameter violation (e.g., a spending-limit breach) executed. Aggregate task pass rates also reflect whether each model followed the discovery protocol and satisfied response-quality checks; those misses are not authorization failures. Furthermore, by allowing agents to dynamically acquire cross-role capabilities mid-task, skilder preserves problem-solving flexibility while providing hard system-level enforcement.
1 Introduction
Flat tool lists scale poorly in context and selection difficulty, while prompt policies alone do not enforce access boundaries. Skilder packages capabilities into roles and delivers them progressively through one server that blocks calls outside learned skills.
1 Introduction
- Flat tool definitions consume more context and make selection harder as catalogs grow, while prompt instructions are not access controls [5] [3] [6].Exposing unnecessary tools also expands the action space and, without downstream authorization, increases risks such as wrong-domain calls and unauthorized data access.Source: §1 · p. 1
- Specialist-agent orchestration shortens each tool list but adds handoffs, complicates tracing, and does not create deterministic boundaries unless authorization is enforced outside the models [8] [9] [10].p04 and p05 together describe this alternative and its trade-offs.Source: §1 · pp. 1–2
- Skilder packages skills, tools, instructions, and limits into roles, then blocks domain-tool calls unless the tool belongs to a learned skill [10].The agent starts with a role catalog and learns the role required for its task.Source: §1 · p. 2
- Across 13 tasks, some models struggle with discovery, but calls outside a learned role are blocked and a second role can be learned when the task changes domains.The reported limitation concerns discovery behavior, not enforcement after capabilities are acquired.Source: §1 · p. 2
- The paper contributes a role-based discovery design, a 13-scenario harness, and a single MCP server that attaches procedures to roles while enforcing learned scope.Agents can learn additional roles mid-task when work spans domains; those calls appear in the tool log.Source: §1 · p. 2
2 Background and Related Work
Skilder combines skill packaging with an MCP tool interface, delivering tools only through skills the agent has learned. Its focus is company-style catalogs and enforced access, rather than large public skill-pool search or creative-output scoring.
Tool-use and skill standards
Existing frameworks
Progressive disclosure and context window management
- Skilder applies progressive disclosure by showing a short role list first, then letting the model open a relevant role and work with its tools.The interface-level approach cuts context before the model is called, and can be combined with model-side context methods.Source: §2 · pp. 2–3
Agent skill ecosystems and security
3 The Skilder Architecture
Skilder is the MCP server the agent connects to; it progressively reveals roles, skills, and resources while routing domain-tool execution only through learned roles. The session begins with a scoped role catalog and a small platform interface.
3 The Skilder Architecture
- The agent connects to Skilder alone, and the router executes a domain tool only when it belongs to a learned skill.The router is the check that decides whether a tool call is allowed.Source: §3 · p. 3
- init_skilder returns the roles inside the session’s authorization scope without showing their instructions or tools; learning a role reveals its instructions, skills, and tools.Tools from previously learned roles remain available, and calls to unlearned tools return ACCESS DENIED with the available tools.Source: §3 · p. 3
- The learn path can load a role, revisit one of its skills, or fetch a document attached to a skill.The harness used the path prefix hats/ in recorded runs; the product path is now /roles/<name>.Source: §3 · p. 3
- Access starts role-scoped, but learning a second role adds its tools so one thread can cover more than one domain.The role packages the instructions, skills, tools, and limits needed for that capacity.Source: §3 · pp. 3–4
4 Experimental Setup
The evaluation uses a simulated authorization harness to compare three tool interfaces while holding the underlying model constant within each trial. It covers six models and thirteen functional scenarios, with separate treatment of discovery failures and authorization failures.
4.1 Benchmark Harness
- The harness implements the role catalog, tool learning, simulated access control, dollar limit, step order, and fake domain data; results measure this test design, not a live product snapshot.It records tool calls, token use, and final replies.Source: §4.1 · p. 4
- A Skilder trial fails if any scored assertion fails, but failed discovery, role selection, missing governed calls, or response-quality checks do not count as authorization failures.Only a forbidden action that executes after reaching the simulated authorization layer qualifies; none was observed.Source: §4.1 · p. 4
4.2 Baseline Conditions
- Each trial uses one model, changing only how tools reach it: flat injection exposes all tools, multi-agent delegates by domain, and Skilder delivers roles into one thread through call_tool.The multi-agent and Skilder conditions differ in effective inference path: specialists receive fresh higher-priority prompts and extra model calls, while Skilder requires discovery.Source: §4.2 · pp. 4–5
4.3 Models
- Six models span lower-cost, higher-capability proprietary, open-weight, and mid-size profiles; token studies use Claude Sonnet 4.5 only.Functional scenarios 1–10 use ten trials per condition and scenario; institutional scenarios 11–13 use five.Source: §4.3 · p. 5
4.4 Benchmark Suites
- The functional suite has thirteen scenarios; behavioral checks can be passed by all three agents, while structural checks test interface properties such as blocked tools or sequence rules.Theme totals separate those checks from ordinary task success; the supporting token study covers 15–225 tools and multi-turn cost at 225 tools.Source: §4.4 · p. 5
5 Multi-Model Functional Results
This section reports Skilder’s functional results across 13 scenarios and six models, distinguishing task success and response quality from discovery-protocol completion and structural access enforcement. It examines role-scoped enforcement alongside cross-domain role discovery, noting that end-to-end success can depend on models following the discovery protocol.
5.1 Structural Governance
- Skilder’s structural governance blocks tools outside learned roles and roles outside session scope; behavioral or discovery-protocol misses are not router enforcement breaches.Across the tested runs, a true platform miss would require a forbidden call to execute after the model learned a role and issued the call; none was observed.Source: §5.1 · pp. 6–7, §5 · p. 6
5.1.1 Scenario 5: Multi-turn adversarial
- Skilder reached 60/60 on Scenario 5 by excluding System Admin, while full-roster multi-agent reached 0/60 on structural isolation and flat-injection executed destructive admin calls in 23/60 trials.Full-roster multi-agent was behaviorally safe in 57/60 trials; adding an explicit support-role policy raised it to 60/60 and provided structural isolation.Source: §5.1.1 · p. 7, Table 2 · p. 7
5.1.2 Scenario 6: Over-limit refund
- Skilder enforced the $500 ceiling in 60/60 Scenario 6 trials, although behavioral success was 48/60 because some models issued inappropriate in-limit partial refunds or failed to escalate.Full-roster and policy-scoped multi-agent scored 0/60 on the structural column: neither configuration added an amount check to the direct refund tool.Source: §5.1.2 · p. 8, Table 3 · p. 8
5.1.3 Scenario 7: Role selection
- Both governed conditions achieved 60/60 structural isolation in Scenario 7, while full-roster multi-agent scored 0/60 because Billing Admin remained reachable.Skilder blocked the out-of-scope Billing Admin role at catalog lookup; the explicit multi-agent roster policy omitted it.Source: §5.1.3 · pp. 8–9, Table 4 · p. 9
5.1.4 Scenario 8: Ambiguous account activity
- Scenario 8 behavioral success was 60/60 for flat-injection, 57/60 for full-roster multi-agent, 59/60 for policy-scoped multi-agent, and 53/60 for Skilder; all mediated conditions scored 60/60 on structural enforcement.All seven Skilder behavioral misses were Ministral trials, and none was a structural breach; flat-injection’s structural score was 0/60 because flagging was reachable from turn 1.Source: §5.1.4 · p. 9, Table 5 · p. 9
5.2 Institutional Policy: Delivery, Adherence, and Enforcement
- Scenario 11 end-to-end success was 22/30 for flat, 12/30 for multi-agent, and 19/30 for Skilder; Scenario 12 complete success was 20/30, 9/30, and 19/30, respectively.In Scenario 12, all interfaces retrieved the policy in 30/30 trials, while Skilder prevented refunds before credit decline in 30/30 trials.Source: §5.2 · p. 11, Table 6 · p. 11
- 0/30 premature refunds executed with either flat+gateway or enforced Skilder; their end-to-end success was 27/30 and 24/30, respectively.Across Scenario 13, flat injection and Skilder share the strongest pooled end-to-end result at 62/90, compared with 30/90 for multi-agent. The sequence guard prevents unsafe execution but does not guarantee task completion when models fail to recover from a valid denial.Source: §5.2 · p. 11
5.3.1 Scenario 9: Support then fraud discovery
- In Scenario 9, Skilder passed 53/60 trials, matching multi-agent at 53/60 and nearing flat-injection at 55/60 after learning Security & Fraud mid-thread.The second learn is an intentional, logged role expansion; misses included acting without that learn or underspecifying investigation advice.Source: §5.3.1 · p. 12
5.3.2 Scenario 10: Proactive role expansion
- In Scenario 10, Skilder passed 38/60 trials versus 35/60 for flat-injection and 30/60 for multi-agent, testing proactive discovery of two needed roles.Some frontier models did worse on Skilder than flat injection because two learn calls required planning; low Qwen and Ministral scores reflected failure to issue the second learn, not router denial.Source: §5.3.2 · pp. 12–13
Does adaptability undermine governance?
- Role expansion remains bounded: agents can learn only roles in session scope, and call_tool independently limits callable tools to learned roles.The role-selection scenario’s out-of-scope Billing Admin learn was denied at catalog lookup, while Security & Fraud was a valid cross-domain expansion; learn calls are visible in the log.Source: Does adaptability undermine governance? · p. 13
5.4.1 Scenario 1: Refund request
- In Scenario 1, successful Skilder refunds followed an entitlement check before processing, while Qwen passed 1/10 versus 5/10 for flat-injection and Opus passed 7/10 versus 10/10.Opus’s three failed trials passed deterministic checks but failed the customer-facing response rubric; the misses were not router errors.Source: §5.4.1 · p. 14
5.4.2 Scenario 2: Simple lookup
- In Scenario 2, Gemma 4 31B and Haiku 4.5 scored 10/10 across all setups, while Qwen 3.5 122B scored 6/10 on Skilder versus 10/10 on flat-injection.The passage attributes Qwen’s gap to protocol overhead rather than failure on the lookup path.Source: §5.4.2 · p. 14
5.4.3 Scenario 3: Error recovery; 5.4.4 Scenario 4: Role disambiguation
- After a failed lookup, both agents withheld process_refund; on vague billing input, successful runs began with lookup_customer, and Skilder selected support or billing rather than security.For Skilder, the CUSTOMER_NOT_FOUND response passed clearly through call_tool, supporting recovery without a downstream action.Source: §5.4.3 · pp. 14–15, §5.4.4 · p. 15
5.5 Cross-Model Summary
- In the institutional suite, flat injection and the Skilder product condition tied at 68.9%, while multi-agent reached 33.3%.Skilder reached the same result through progressive role-scoped delivery; its distinction is structural policy visibility and separately enforceable workflow steps.Source: §5.5 · p. 15
- Across Scenarios 1–4, Skilder’s pooled end-to-end pass rate was 198/240 versus flat-injection’s 229/240; Gemma 4 31B, Haiku 4.5, and GPT-5.5 each scored 40/40.The gap is attributed to Qwen, Ministral, and three Opus Scenario 1 rubric misses, rather than a governance leak.Source: §5.4.4 · p. 15, §5.5 · p. 16
6 Discussion
The three interfaces differ in role scoping, model-dependent discovery, and what their scores capture. The discussion cautions that the simulated harness and model pool constrain how to interpret the results.
6.1 What the three interfaces actually differ on
- Flat-injection is simplest and can win trivial lookups, but exposes every tool from turn 1; model capability and interface design need evaluation together.The same model’s results vary with task framing, and institutional product-condition trials range from all completed by Opus and GPT-5.5 to only 6/15 by Qwen and Ministral.Source: §6.1 · p. 16
- Scenario 6 results range from 6/10 to 10/10 for role-matched multi-agent, 0/10 to 2/10 for flat-injection, and 1/10 to 10/10 for Skilder.The lower multi-agent and Skilder cells include unsolicited partial refunds; under Skilder, those transactions satisfy the platform’s amount ceiling but not the customer workflow.Source: §6.1 · p. 16
- Progressive discovery requires init→learn→call_tool; Qwen and Ministral miss that sequence more often than enforcement, unlike Haiku, Gemma, and GPT-5.5.Pooled Skilder totals combine router holds with trials that never issued a governed call.Source: §6.1 · p. 17
6.2 Scoring notes
- A trial fails if any non-N/A check fails, mixing Skilder-only protocol checks, shared behavioral checks, and structural checks into one score.Scenarios 5–8 and 11–13 were rerun with specified role bindings, assertions, or ablations; other scenarios were not recoded, and the remaining response-quality rubric has no numeric threshold.Source: §6.2 · p. 17
6.3 Limitations
- The authorization layer is a simulated implementation of the role design, not a live product snapshot; domain tools return fixtures, not live MCP responses.Scaling measurements are single-run, Sonnet 4.5 only, and use no prompt caching; some models also struggle with discovery and nested call_tool arguments.Source: §6.3 · p. 17
7 Token cost versus catalog size
The scaling study measures token use as a company-style tool catalog grows. Progressive discovery costs more at small catalogs but uses substantially fewer tokens than flat injection at the largest tested size.
7 Token cost versus catalog size
- The study varies total tool count from 15 to 225, with R = N/15 roles of approximately 15 tools each.Each synthetic role has one skill of about 15 tools and a minimal instruction block; the skill layer is flattened because the study measures tool-definition volume.Source: §7 · p. 17
- At 225 tools, one customer lookup uses 9,084 tokens with Skilder and 51,330 with flat-injection.At N=15, init→learn→call_tool uses more tokens than a direct tool call; near 30 tools, Skilder and flat-injection are essentially equal.Source: §7 · p. 17
- Context stays at four platform tools plus a short role catalog as N grows; multi-agent can use fewer tokens for one delegation but more when policy is re-loaded at every handoff.The study’s multi-agent comparison is not wholly measured: the stated large-N series is interpolated, while Skilder and flat-injection measurements are not.Source: §7 · p. 17
8 Conclusion
Skilder packages capabilities into roles and enforces learned scope at one MCP server. The evaluation reports governance enforcement, policy delivery, adaptability, ordinary-task results, and token use as catalogs grow.
8 Conclusion
- Out-of-scope and over-limit calls are denied at the router once a role is learned; low pooled governance scores can reflect models that never reached the router.On ordinary tasks, Haiku, Gemma, and GPT-5.5 match flat-injection; remaining misses are mostly failed discovery by Qwen and Ministral, plus Opus treating role policy as injection.Source: §8 · p. 18
- Roles carry company-specific ladders and brand language to the teams that need them, while a fair flat baseline receives the same policy tool globally.A second role can be learned when a thread crosses domains, and the extra learn appears in the tool log.Source: §8 · pp. 17–18
- Token use under Skilder stays nearly flat as the catalog grows from 15 to 225 tools.Figure 2 shows total tokens for a single-turn lookup: Skilder stays near-constant while flat-injection grows linearly; the multi-agent series at large N is interpolated.Source: §8 · p. 18, Figure 2 · p. 18
- Planned future work includes real MCP integration, larger catalogs, production telemetry, and deeper hierarchies.The authors also plan to re-grade saved transcripts and analyze discovery misses and Opus’s handling of role-embedded policy.Source: §8 · p. 18
A Scenario 5 Full Multi-Agent Scoping Ablation
The appendices preserve per-model results behind the paper’s compact summaries and document the scaling study’s scope and measurement limits.
A Scenario 5 Full Multi-Agent Scoping Ablation
- Appendix A preserves per-model results underlying the compact Table 2 summary.Source: A Scenario 5 Full Multi-Agent Scoping… · p. 21
B Scenarios 6–8 Structural Governance Decomposition
- Appendix B preserves per-model tables behind the main-text behavioral-versus-structural summaries.Source: B Scenarios 6–8 Structural Governance… · p. 21
C Scenarios 11–13 Institutional Policy Outcomes
- Appendix C gives complete per-model end-to-end results for scenarios 11–13; all conditions share policy content and protocol, with two gateway ablations in Scenario 13.Source: C Scenarios 11–13 Institutional Policy… · p. 21
D Scaling Benchmark: Full Results
- The scaling study measures single-turn lookup token use and latency from 15 to 225 tools; runs are n=1 per configuration without prompt caching.Several multi-agent coordinates are rounded interpolations, not additional measured samples; Figure 2 shows total tokens only.Source: D Scaling Benchmark: Full Results · p. 21
D.1 Library Growth on a Single-Turn Lookup
The single-turn lookup comparison shows flat-injection token use rising with library size, while Skilder stays nearly constant; its setup overhead is outweighed at larger catalogs. Multi-agent costs are also near-flat and can be lower on this simple task.
D.1 Library Growth on a Single-Turn Lookup
- On the simple lookup, multi-agent cost stays near-flat and can be below Skilder when one delegation suffices, while flat-injection grows linearly.The benchmark varies library size across seven scale levels and assigns about 15 tools per role.Source: §D.1 · p. 24
- At small catalogs, init→learn→call_tool adds tokens; that overhead becomes small relative to injecting every tool definition as the catalog grows.The crossover between Skilder and flat-injection occurs at about 30 tools.Source: §D.1 · p. 24, Figure 3 · p. 24
- 4,404 to 51,330 total tokens for flat-injection versus 7,247 to 9,084 for Skilder as catalogs grow from 15 to 225 tools.The reported increases are 11.7× for flat-injection and 1.25× for Skilder.Source: §D.1 · p. 24, Figure 3 · p. 24
- Flat-injection includes every tool definition on each API call, while Skilder includes four platform tools and a slowly growing role catalog.The token gap is almost entirely in input tokens; output tokens are similar.Source: §D.1 · p. 24
D.2 Latency and Turn Overhead
Skilder’s discovery path adds fixed latency and turn overhead, while the turn-cost benchmark compares its input-token costs with multi-agent orchestration at increasing conversation depth. The latter comparison uses only comparable workflow attempts, with T=4 multi-agent values treated separately when no comparable run succeeds.
D.2 Latency and Turn Overhead
- 9–12s for Skilder versus 3–5s for flat-injection reflects three sequential model round-trips versus one; the latency overhead is fixed as tool count grows.The associated crossover occurs at N ≈30.Source: §D.2 · p. 25
- 4 turns for Skilder versus 2 for flat-injection on the lookup task creates constant turn overhead, independent of catalog size.Skilder uses init, learn, and call_tool after the user message; flat-injection goes directly to a tool call.Source: §D.2 · p. 25
E Turn-Cost Benchmark: Comparability and Multi-Agent T=4
- The turn-cost study reports input tokens at depths T=1–4 on a 225-tool catalog, keeping the first comparable run within three attempts.At T=4, multi-agent values without a comparable run are minimum-observed inputs, not fair comparisons.Source: E Turn-Cost Benchmark: Comparability… · p. 25, Table 23 · p. 25
E.1 Multi-Turn Conversation Cost (Thin vs. Rich Context)
As user turns accumulate, rich-context multi-agent orchestration incurs repeated policy and delegate-payload costs, while both Skilder configurations retain a single thread. The T=4 multi-agent points are best-effort minima from failed workflows rather than comparable costs.
E.1 Multi-Turn Conversation Cost (Thin vs. Rich Context)
- Rich context adds a roughly 3,000-token policy document; multi-agent re-loads it on delegation, while Skilder learns it in the same thread.The study crosses two interfaces and two context payloads at depths T=1–4.Source: §E.1 · p. 26
- At T=3, multi-agent rich context uses 23,481 input tokens, versus 19,445 for Skilder rich context and 18,482 for Skilder thin context.The measured ordering is multi-agent rich > Skilder rich > Skilder thin > multi-agent thin.Source: §E.1 · p. 26, Figure 4 · p. 26
- At T=1, multi-agent thin context has the lowest input tokens; as turns accumulate, multi-agent rich context climbs fastest because delegation can restart sub-sessions and re-ingest prior payloads.At T=3, the measured ordering places multi-agent rich context highest.Source: §E.1 · p. 26, Figure 4 · p. 26
- At T=4, Skilder thin and rich context achieve comparable runs at 25,874 and 26,251 input tokens, respectively; neither multi-agent configuration achieves a comparable run.The multi-agent minima of 26,867 and 32,494 tokens are lower bounds from failed workflows, not fair best-case costs.Source: §E.1 · p. 27
- Multi-agent T=4 open-marker values are minima from three attempts without a comparable workflow, so they do not establish its best possible cost against Skilder.Comparable trials required the correct turn count and required tools, no forbidden tools, and tool and delegation counts within budget.Source: §E.1 · p. 27
F Scenario 1 Opus 4.7 Failure: Verbatim Run
Three Opus 4.7 refund trials failed response-quality checks despite passing deterministic governance checks and escalating the over-limit refund. The institutional-policy audit distinguishes blocked actions from task failures, while a separate Scenario 8 trace illustrates role-scope transitions before consequential tools become reachable.
F Scenario 1 Opus 4.7 Failure: Verbatim Run
- Three of ten Claude Opus 4.7 Skilder trials in the combined six-model evaluation failed Scenario 1 despite every deterministic check passing, because final responses leaked platform narration and rejected role-resident policy as adversarial prompt injection.The request exceeded Tier 1’s $500 authority, so it was escalated; process_refund was not called.Source: F Scenario 1 Opus 4.7 Failure:… · p. 28, Skilder agent: tool sequence · p. 28
Prompt
- The customer requested a refund for an Enterprise feature failure; the transcript shows Opus describing the role instructions as manipulative and saying it would ignore them.The final response also narrated platform mechanics and the internal workflow.Source: Prompt · p. 28, Skilder agent: final response (verbatim) · pp. 28–29
Assertion results
- The assertion results separate protocol and governance passes from a response-quality failure for customer-facing commentary about Skilder, hats, prompt injection, and workflow.The harness marked the reply helpful substantively but not cleanly protocol-compliant.Source: Assertion results · p. 29
Interpretation
- The authors attribute the three losses to a scoring mismatch: router checks passed and the over-limit refund was escalated, but Opus narrated platform mechanics and rejected policy instructions.The harness does not yet separate platform correctness from defective model prose.Source: Interpretation · p. 29
- The harness limitation is that it counts response-quality failures as end-to-end losses without separating them from genuine protocol failures.The authors leave open whether the observed overcaution around policy-bearing roles is a deployment concern.Source: Interpretation · p. 29
G Institutional-Policy Trace Audit
- In the institutional-policy audit, guidance-only conditions had no blocked calls and premature refunds executed in 9/30 flat, 18/30 multi-agent, and 5/30 Skilder trials; guarded conditions had zero premature executions.Flat+gateway recorded eight blocks and six recoveries; enforced Skilder recorded twelve blocks and eight recoveries, with four unrecovered task failures whose invalid actions did not execute.Source: G Institutional-Policy Trace Audit · p. 29
- The five-condition comparison attributes the shared safety property to the external policy plane in both guarded designs, while Skilder additionally provides progressive role scope.The audit separates sequence-guard effects from role-scoped discovery.Source: G Institutional-Policy Trace Audit · pp. 29–30
H Scenario 8 Illustrative Trace: Investigate Before Flagging
- In the Scenario 8 trace, all three conditions passed the behavioral sequence, but only scoped interfaces made the flagging tool reachable after an explicit scope transition.The scoped designs scored 1 on the structural metric; flat-injection scored 0 because the tool was reachable from turn 1.Source: Observed sequences · p. 30