It reads your TypeScript, Python or Ruby and checks what the code does at every boundary, such as a route or a table, against the clients, specs and infrastructure on the other side. No model is involved, so the same code gives you the same answer every time.
suss inspect --diff reads the summaries from before a change and the ones from after, and prints the boundaries whose behavior moved:
1 boundary changed: 1 outcome.
~ serves GET /orders/{reference} src/api.ts::get (1 outcome)
outcomes
~ responds 200 { reference, total, -placedAt } otherwise
Changes by file
src/api.ts
~ getplacedAt is no longer in the success body. In the text diff that is one changed line among all the others, and a reviewer has to spot it. Nobody wrote the description above by hand. suss worked it out from the source without running your code or using a model, so the same source gives you the same answer every time.
init, extract and inspect on a project you already have. At the end you have a description of your service, and nothing to triage. suss map gives you the same as one page you open from disk, as in this map of lobsters.suss reads a project through one pack per library, so you get a pack for your web framework and another for your ORM. suss init works out which packs you need, and the pack catalog lists them. Every pack ships inside @suss/cli, so there is one install.
TypeScript is the furthest along. In Python and Ruby, suss reads routes and a smaller set of ORMs. Read Python or Ruby describes where each language stops. One run reads one repository. To check across two repositories, you publish one side's summaries and hand them to the other side's run; see Work across services. Compatibility has the rest of the limits.
Four ideas explains the four words the rest of the documentation uses: boundary, summary, check and pack.