Skip to main content
Glama

triz_dynamics

Explores bounded dynamics of finite-state function models via breadth-first search, checking reachability, safety, timed separation, loop classes, and cycle-cost bounds with witness traces.

Instructions

Costed transition rows add exact per-dimension cycle mean ranges, rational potential bounds and rechecked witnesses on closed components; max_cost_work caps these. Bounded dynamics of a function model whose boxes declare state, initial, and transition rows (state, inputs) → (next state, outputs): each such box is a nondeterministic Mealy machine (a lens with a residual is one, with the residual as state); boxes with behavior are stateless. Boxes compose synchronously along the wiring: wires are instantaneous, memory lives only in declared state, and a loop through stateless boxes resolves within a step as in triz_behavior. From the initial states, over the boundary inputs you allow at each time (default: every value), every run is explored breadth first up to horizon steps; the result lists the reachable states, the fixed points among them, and the runs that block (a state with no row for its inputs). unsafe decides escalation: reachable (with a shortest trace), unreachable (the reachable set stopped growing, so at no horizon), or unreachable-within-horizon. safe decides invariance: violated (shortest trace), invariant, or invariant-within-horizon. Without inputs the configurations are finite, so each verdict also carries unbounded, decided at every horizon by continuing the search past the horizon within the same state cap: reachable or violated (with the time and, past the horizon, a shortest trace), unreachable or invariant (with completeAfter), or undecided (cap-exceeded past the horizon, or blocked); the bounded verdict beside it is unchanged. A blocked state meets a target by its state conditions; a port condition there leaves the verdict undecided (reason blocked), never safe. separation takes two to four demands, each a target set with a time window, and decides whether one run visits each within its window (separation in time along a trajectory, Principle 15): realizable with a witness trace, unrealizable (a demand never met, or no single run meets them all), or undecided (a blocked run might meet them all). Without inputs, loops classifies the closed components (no step leaves them) of the reachable graph of the global states of boxes that declare transition, explored without a horizon up to the cap, from the initial states and every state meeting safe's state conditions: bistable (fixed points in two or more closed components), trapped (a closed component every configuration of which meets unsafe: an absorbing trap, with a shortest trace into it), recurrent (a closed component that meets unsafe and also holds a safe configuration: the run can recover but never leaves it, with a shortest trace into it and the safe configuration), oscillating (a cycle and no fixed point, with its period and one cycle); each closed component reports unsafe (it meets the set) and allUnsafe (it lies inside it); classes can coexist, and 'none' means no closed component was found within the cap. Behavior rows are never read as transitions. Every trace is re-checked against the declared rows. Fails closed on ill-typed rows, unknown targets, and past the state cap. Verdicts hold for the rows as declared; continuous dynamics, convergence rates, and control are not modelled.

Input Schema

NameRequiredDescriptionDefault
safeNoInvariance: does every reachable configuration meet every condition?
modelYes
inputsNoEntry t lists the values allowed at time t on unwired input ports; an unlisted port takes every value. Omit for every value at every time
unsafeNoEscalation: is a configuration where every condition holds reachable? e.g. [{ box: 'bearing', port: 'friction', values: ['high'] }]
horizonNoSteps to explore (times 0 to horizon); default: the length of inputs minus one, else 20
initialNoBox id → initial states, overriding the box's initial
max_statesNoCap on configurations and search states (default and maximum 100000)
separationNoSeparation in time: does one run visit each demand's target set within its window?
max_cost_workNoExact cycle-cost work cap; past it meanCost is undecided

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.1

TDQS

B3.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the whole burden and does so extensively: it discloses breadth-first exhaustive exploration, the default horizon (inputs length minus one, else 20), the state cap, that it fails closed on ill-typed rows, unknown targets, and past the cap, that every trace is re-checked against declared rows, and that continuous dynamics, convergence rates, and control are not modelled. It also explains the `unbounded` post-horizon continuation of each verdict and what 'undecided' means. The return shape is only described in prose fragments (no output schema exists), which keeps it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single wall of run-on clauses with no headings, lists, or paragraph breaks, making the four distinct analyses (reachability, invariance, separation, loop classification) hard to locate. The lead sentence is the least useful content yet is front-loaded, and heavy jargon ('rational potential bounds', 'rechecked witnesses on closed components') is never grounded. Length is justified by tool complexity, but the lack of structure is not.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter, deeply nested model-checking tool with no output schema, the description covers the semantics of the main verdicts and the failure/limit behavior well. It is weaker on the return contract: fields like `completeAfter`, `unbounded`, `allUnsafe`, and meanCost appear only in passing, and the opening sentence about costed transition rows is never explained, so an agent cannot fully anticipate the response. Adequate but with clear gaps for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 89%, so the schema already documents most parameters and the baseline is 3. The description does add real meaning in places — that `inputs` defaults to every value at every time, that `max_cost_work` caps exact cycle-cost work and leaves meanCost undecided, that `separation` takes two to four demands with non-overlapping windows, and that a blocked state meets a target by state conditions but a port condition there yields undecided. These additions are genuine but scattered through dense prose rather than tied clearly to each parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: it explores the bounded dynamics of a function model whose boxes declare `state`, `initial`, and `transition` rows, doing breadth-first search from the initial states up to `horizon` and returning reachable states, fixed points, and blocking runs. It separates itself from `triz_behavior` ('a loop through stateless boxes resolves within a step as in triz_behavior'; 'Behavior rows are never read as transitions'), so an agent can tell the two apart. The opening sentence about 'costed transition rows' and 'rational potential bounds' is opaque and sits before the actual purpose, slightly hurting first-read clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied through what each parameter decides — `unsafe` for escalation, `safe` for invariance, `separation` for a trajectory meeting timed demands, `loops` for closed-component classification — which gives a reader a fair idea of when to reach for the tool. However there is no explicit 'use this when / do not use this when' statement and no direct routing to `triz_behavior`, `triz_feasibility`, or `triz_lifecycle` for the adjacent questions they answer. The prohibition on reading behavior rows as transitions is the only explicit boundary.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.