Reading the Capability Boundary

MathModelAgent’s runtime makes a useful audit possible: a reader can compare what the project says it supports with what the current code, message path, and artifacts actually show. This chapter applies that audit to optional features, generated output, and operational safeguards. The aim is not to accuse the project of failing whenever a roadmap item is unfinished. It is to teach a calibrated judgment: implemented, partial, and not established are different states.

A public README is a map of intention. A running workflow is evidence of a path. A setting or data schema is evidence that a concept has a place in the design, but not necessarily that the concept changes behavior. A frontend view or persisted artifact shows another part of the lifecycle. Trust improves when these layers agree; uncertainty should remain visible when they do not.

Test a feature claim across its lifecycle

A repeatable audit begins with the claim itself. What does the feature promise the user? Is it a search action, a retrieval step, an approval pause, a fallback decision, or an evaluator-driven rerun? The wording determines what must be observed. A feature that promises human approval should not be considered present merely because an approval object can be serialized. The workflow must pause, expose a decision, accept an action, resume or abort accordingly, and show the result to the user.

The next step is to find configuration and schemas. These show that the project has named the feature and decided what data or settings it might need. They are useful evidence of architectural intent and future extension. They are not evidence that the main workflow invokes the feature. The audit must then follow call sites: where is the feature constructed, who calls it, what triggers it, and what output does it change?

Transport and UI handling are the next boundary. A backend may publish an event that the frontend does not accept, render, or act on. A configuration switch may be read by a service that has no effect on the workflow path the user actually starts. The runtime chapter showed why this matters: capability lives across state, messages, and projections, not in one file.

The final test is an observed artifact or a controlled failure. If a search feature is implemented, a run should show the query and result path. If a fallback is implemented, a provider failure should produce a documented transition. If an evaluator is implemented, an output should be scored and fed into a bounded rerun. If no such path is visible in the inspected snapshot, the careful conclusion is “not established here,” not “impossible everywhere.”

flowchart LR A["Advertised feature"] --> B["Configuration or schema"] B --> C["Workflow call site"] C --> D["Transport and UI handling"] D --> E["Observed artifact or failure"] E --> F["Implemented, partial, or not established"]

This method prevents two opposite mistakes. The first is accepting promotional language as proof. The second is inferring that a feature does not exist solely because one partial file does not mention it. The repository’s own roadmap, current worktree, call paths, and UI behavior should be read together, with the conclusion limited to what those sources establish.

It also helps separate three different diagnoses.