Skip to main content
Glama

triz_abstraction

Check whether a coarse function model correctly abstracts a detailed one under a typed box, port, and carrier map, and report failing checks, hidden functions, and harm loops.

Instructions

Check that a coarse function model (few boxes, e.g. with declared behaviour) is an abstraction of a detailed one of the same system (many boxes, e.g. with costs and feasibility) under a typed map: detailed box → coarse box (several may share one; a box left out is outside the abstraction), per box detailed port → coarse port (default: the same id and side), detailed carrier → coarse carrier (default: the same id). A function between two mapped ports is mapped; one between unmapped ports of boxes with the same image is hidden inside that coarse box; one between boxes with different images and an unmapped port is forgotten. Four checks: total (every mapped port's carrier has an image, and every mapped function has an image coarse function with the mapped endpoints, the mapped carrier, and the same polarity class: negative = harmful or excessive, or not), typed (each mapped port lands on a port of the same side whose carrier is its carrier's image, of the same layer; typed_map), wires (every coarse function is the image of a mapped detailed function of its class), harm loops (every coarse harm loop is the image of a detailed one: each harmful or excessive coarse function on it has such a preimage whose object reaches its performer along mapped and hidden functions; cycle_map, with the detailed cycle as witness). Verdict abstraction or not-an-abstraction with the failing checks. Also reports the functions hidden, forgotten, and left out (harms listed apart), the detailed harm loops the coarse model hides or loses, whether reachability among mapped boxes passes to the coarse model (reach_map, when nothing is forgotten), and, where a coarse box with behaviour has one preimage box with feasibility, whether that box's feasibility amounts read through the coarse carriers' levels fall in the coarse behaviour. When either model declares flows, each detailed flow's runs inside the mapped boxes are sent through the map like a merge and matched step by step against the coarse flows of the image carrier (flows.images), and coarse flow steps no detailed step maps to are listed (flows.unbacked); flows do not change the verdict. Fails closed on a model that does not type-check and on map ids that do not exist. Whether the coarse rows are true of their preimages is substantiated outside the kernel.

Input Schema

NameRequiredDescriptionDefault
mapYes
coarseYesThe coarse model of the same system
detailedYesThe detailed model

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.5.1

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does most of it: it discloses the four checks by name, the verdict shape, that extra reports (hidden/forgotten/left out, harm loops, reach_map, feasibility, flows) accompany the verdict, that flows do not change the verdict, and that it fails closed on ill-typed models or nonexistent map ids. Missing only cost/determinism or error-payload details.

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

Conciseness3/5

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

Purpose is front-loaded, but the body is a single wall of multi-clause sentences with heavy parentheticals (the initial 'e.g. with declared behaviour' vs 'with costs and feasibility' framing is buried). Naming output keys inline (typed_map, cycle_map, reach_map, flows.images, flows.unbacked) is useful, but the density makes skimming hard; some phrasing, such as 'negative = harmful or excessive, or not', is needlessly convoluted.

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

Completeness5/5

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

For a three-parameter tool with deeply nested models, no output schema, and no annotations, the description covers what an agent needs: the mapping defaults, the four checks, the verdict and failing checks, the auxiliary reports, the flows behavior, and the failure mode. Return-value detail is spelled out precisely because no output schema exists.

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?

At 67% schema coverage, the schema already documents the AbstractionMap sub-fields with the same defaults ('same id and side', 'a box left out is outside the abstraction') that the description restates. The description does add some semantics by tying map entries to consequences (unmapped ports become hidden, differing images plus an unmapped port become forgotten), but most map mechanics duplicate the schema text.

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

Purpose5/5

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

Opens with a specific verb and relation: 'Check that a coarse function model ... is an abstraction of a detailed one of the same system under a typed map'. The typed-map framing plus the named verdicts ('abstraction or not-an-abstraction with the failing checks') make it distinguishable from verification-adjacent siblings such as triz_adequacy or triz_isomorphism without opening any schema.

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 rather than stated: one infers this is the tool for validating a coarse model against a detailed one, and the closing sentence scopes it ('Whether the coarse rows are true of their preimages is substantiated outside the kernel'). No sibling is named as an alternative and no precondition (e.g. models must type-check, provenance status) is given up front.

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