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 came off the success body. In the text diff that is one changed line among all the others, and the reviewer has to notice it. Nobody wrote the description above by hand. suss worked it out from the source, without running your code and without a model, so the same source gives you the same answer every time.
init, extract and inspect on a project you already have. There is nothing to triage at the end of it. What you get is a description of your service.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, and where each language stops is covered in Read Python or Ruby. Both sides of a boundary have to be in one repository for suss to compare them, so a front end in a second repository is a second run for now. Compatibility has the rest of the limits.
Four ideas explains the four words the rest of the documentation leans on: boundary, summary, check and pack.