Review enrichment
By the end of this page you will know what enrichment adds, and how to review a batch of it without it feeling like data entry.
Prerequisites
- An application ingested with enrichment on (Run an ingest).
- Admin or Developer role.
What enrichment is
An optional ingest stage that asks a model what the parsers structurally cannot know:
- A real type for files the analysis could only call
Util. - A one-sentence description for the nodes a reader meets first.
- The domain concepts the endpoints talk about but nothing persists.
- The authorization pattern of each endpoint group.
That last one is the example worth holding on to: it is how an unauthenticated POST/PUT/DELETE on a public route stops being something you have to notice yourself and becomes a node with edges pointing at what it protects.
Enrichment is off by default, never fails an ingest, and is bounded by a hard per-job call ceiling. Everything it produces is marked as inferred and lands here for review — nothing it claims is applied silently.
The screen is built for triage
On a first ingest most of what enrichment proposes is unremarkable and a handful genuinely deserve judgement. Treating both the same is what makes review feel like a chore, so this screen separates them:
- A progress bar, so you can see how much is left rather than guessing.
- Accept all high-confidence items as one action — which is what makes reviewing the rest carefully affordable.
- The remainder grouped by the question each pass was asked, because judging a batch of descriptions is a different mental task from judging a batch of authorization findings.
- The evidence in words — what the model wrote, what it replaced, and why. An edge reads as
auth: anonymous-all → DELETE /api/products/{id}, not as two node ids.
Keyboard
j and k move. c accepts, e edits, x rejects, u undoes. A reviewer working through a list should not have to reach for the mouse on every row.
The statistics
| Stat | What it tells you |
|---|---|
| Proposals · Applied | How many were made, and how many you have accepted |
| Agreed with parser | Where the model confirmed what the analysis already found — reassuring rather than informative |
| Refused | Where it declined to guess |
| LLM calls · Credits | What the pass cost |
Two rules worth knowing
The model may describe things, but never identify them. Anything it creates comes from a closed vocabulary, so a decision you make about one item survives the model rewording itself on the next ingest.
Your decisions outlive the ingest that produced them. A correction is stored outside the immutable version and applied on read — so an inferred edge you delete stays deleted through every future ingest. You are not re-reviewing the same proposals forever.
Common issues
- There is nothing to review — Enrichment was off for that ingest.
- The same proposals come back after re-ingesting — They should not. If they do, the decision was not saved; check the item is marked applied.
- A description is wrong — Edit it rather than rejecting it. The correction persists.
- The credit cost looks high — Enrichment is bounded per job, but a large application still costs more than a small one. Turn it off for routine re-ingests and on when the descriptions matter.