Skip to main content
Glama

triz_behavior

Compose declared box behaviors into a model's external input-to-deliverable relation, compare or trim against a baseline, and derive safe missing-box specifications.

Instructions

Compose declared box behaviour (carrier values, box behavior rows) into the model's external relation: boundary inputs (unwired input ports) to deliverables (product input ports fed by a non-harmful function). The default upstream scope composes boxes that can reach a deliverable and explicitly assumes omitted boxes accept everything; scope whole composes every box, including downstream and disconnected constraints. full_relation returns all rows within the search cap. Feedback loops compose by the relational trace, so every consistent steady state counts, and the steady states are listed. factorisations lists each composed box whose relation is the product of its projections onto two or more groups of ports, with the finest groups, in box order (decided:false past a per-box cap): segment it into them, or unions of them, and each part keeps its projection. The hint describes the declared rows, not a physical split, and changes no verdict. This is steady-state semantics, not dynamics. With compare_to, decide whether the model (a concept, e.g. a triz_transform result) has the baseline's input→deliverable relation; pass segment's or take_out's boxMap as box_map. trim is shorthand: perform the trim as triz_transform does and compare the result with the model. Verdict preserved; changed (a lost deliverable, or a counterexample input with the differing outputs and which relation contains which); or undecided (reason missing-behavior: the boxes that can reach a deliverable and declare no behaviour; reason no-steady-state: neither model has a steady state at any input, so equal empty relations say nothing). With joint_boxes and weakest_spec, select every composed box without behavior and compute one coupled residual over their combined ports. The joint rows are a single relation: independentSafe checks whether independently declaring their per-box projections stays inside the target, factorizes checks whether their product equals the joint relation, and a counterexample explains unsafe coupling. The exact search is bounded by max_states; row_costs are unsupported in this mode. With weakest_spec (and compare_to or trim), give the weakest box specification (residual in Rel) for the one box of the concept that can reach a deliverable and declares no behaviour, against the same target: spec, every row of that box whose composite stays inside the target, with preserves:true when declaring it gives exactly the target (any behaviour that does is contained in it); impossible, when the spec's composite misses part of the target (an uncovered input is given; no behaviour of that box gives the target, and the empty relation, which always stays inside, is never read as preserving) or a deliverable is lost; undecided for three or more unknown boxes when joint_boxes is omitted (several-holes), missing baseline behaviour, an empty target, or past the cap (state-cap). When the box to specify declares producible rows (what it can physically produce), the spec is the residual cut down to them: spec when that still covers the target (producible.infeasible lists the residual rows left out); impossible with reason infeasible when the residual covers the target but its producible rows do not, with requiredInfeasible giving, per missing target pair, the residual rows that deliver it, none producible (every relation that gives the target contains one of each); impossible with reason not-covered when the residual itself does not cover. With exactly two boxes without behaviour (boxes), a pair of relations stays inside the target iff every pair of rows, one of each, does, and the maximal such pairs are the formal concepts of the safe row pairs: spec lists those whose composite covers the target (specs, each declared and re-checked to give exactly the target; every pair that gives the target lies inside one), with weakest:true when there is one and weakest:false when several are incomparable; impossible (not-covered) when none covers, with each maximal pair's uncovered input (pairs); undecided (concept-cap) past the cap on concepts. Producible rows cut each box first; impossible with reason infeasible then means some pair over all rows (wouldGive) would give the target. Fails closed on ill-typed behaviour, an ambiguous or mismatched box_map, inputs whose values differ between the models, and past the state cap. With row_costs in the one-hole mode, cheapestExtension gives an exact least-cost set of safe nonproducible rows to add, using the complete target relation and explicit integer costs, or reports an undecided capped search; it is not-applicable (target-not-covered-by-residual) when the residual itself misses the target, and row_costs fail with invalid-row-costs wherever no one-box residual is computed; the Boolean verdict is unchanged. The verdict holds for the relations as declared; substantiating them, the absorber's or mediator's first, is outside the kernel.

Input Schema

NameRequiredDescriptionDefault
trimNoBoxes to trim; with it, decide whether the trim preserves the external behaviour
modelYesThe model to compose (the concept, when compare_to is given)
scopeNoDefault upstream assumes omitted boxes accept all received values; whole composes every declared box constraint
absorbNoWith trim: function wire id → absorber output port; default: the first absorber triz_trim lists
box_mapNoWith compare_to: concept box id → baseline box id, applied to deliverables and boundary inputs; pass a triz_transform segment or take_out boxMap here
row_costsNoWith one-hole weakest_spec: explicit cost of every safe nonproducible row that covers an unmet target pair. cheapestExtension finds the least total cost set of additional rows, charging each once. Costs share one caller-chosen unit; no cost is inferred
compare_toNoBaseline model; with it, decide whether the model preserves the baseline's input→deliverable relation
max_statesNoCap on boundary valuations and search states (default and maximum 100000)
joint_boxesNoWith weakest_spec: select every composed box without behavior as one coupled joint relation
effect_hintsNo
weakest_specNoWith compare_to or trim: give the weakest specification for the one box, or the maximal pairs of relations for the two boxes, that can reach a deliverable and declare no behaviour, against the same target
full_relationNoReturn every relation row within the search cap; default output is truncated for display
max_cost_searchNoWith row_costs: cap on exact extension-search nodes (default and maximum 100000); a capped search makes no optimality claim

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.1

TDQS

A3.8/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so extensively: it discloses steady-state semantics, the default upstream scope assumption, search caps, fail-closed conditions, and undecided reasons such as missing-behavior, no-steady-state, and concept-cap. It also explains what verdicts mean and how modes change behavior, which is well beyond what structured fields provide.

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 enormous paragraph of densely compressed jargon with no headings, bullets, or clear progression between modes. Although the first sentence is front-loaded with purpose, the remaining text is difficult to scan and repeats mode conditions in a way that undermines readability.

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

Completeness4/5

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

For a complex 13-parameter tool with no output schema, the description is thorough: it covers default behavior, mode-specific verdicts, failure reasons, caps, and producible-row handling. Some specialized terms such as relational trace and factorisations are left opaque, but the overall informational coverage is high.

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

Parameters4/5

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

Schema description coverage is high at 92%, so the baseline is 3. The description adds real meaning beyond the schema by explaining parameter interactions and provenance, e.g. that box_map should be a triz_transform segment or take_out boxMap, that row_costs are unsupported in joint_boxes mode, and that trim is shorthand for the triz_transform trim procedure.

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 opening sentence states a specific verb and resource: compose declared box behaviour into the model's external relation, defined as boundary inputs to deliverables. It distinguishes the tool from triz_transform and triz_trim only through mode-specific references, not through an overall statement of when this tool is preferred over its siblings such as triz_behavior_refinement.

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?

The description gives explicit mode conditions, e.g. 'With compare_to', 'trim is shorthand', and 'With joint_boxes and weakest_spec'. However, it never names an alternative tool to use instead or states when this tool should not be used, leaving tool selection largely implicit.

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