Passes after finished work

Twice at the boundary of a piece of work the base changes by itself: first an extraction pass reads what has just finished and writes down the lessons; then a consolidation pass puts the base in order.

When they run

There is no schedule. A pass runs at the boundary of real work:

• a task has ended — merged, rejected or stopped. Rejection and stopping are the most valuable boundaries: the reason for the refusal is exactly what the model would otherwise forget;
• the audit pool has emptied — not after every section and not after every run, but when the project has no audits left running; the pass is started by the last one to finish;
• you pressed “Update now” on the pass card in the section — without waiting for the next task to end (change permission is required).

A project runs one pass at a time: a second boundary triggered at that moment quietly does nothing. A boundary that was processed successfully is not processed a second time (a second wave of audits on the same day adds nothing). If a pass did not finish — it failed or was interrupted — the card shows it, and the same boundary will be processed by the next pass or a manual run: an unfinished pass does not count as done and does not keep the base busy.

What the extraction pass does

It reads everything left over from the work. For a task, that is its text and the whole correspondence — clarifications, gate decisions, review findings and how they were resolved, rework requests, the reason for rejection or stopping — as well as the records of the sessions in which its atoms worked, and the resulting code changes. For an audit pool — the report sections, the findings and the summary report.

The most valuable thing for it is your explicit corrections: an answer to a clarification, a rejected formulation, a send-back for rework with a finding. These turn into facts and pitfalls.

Entries in the “task” scope — what the model wrote down in the course of this task — are its material too: it moves into the project those that will outlive the task and leaves the rest. It writes only to the project: the task is closed, and the task scope closes with it.

What the consolidation pass does

• merges duplicates into one entry, keeping both reasons;
• brings titles and descriptions up to date — they feed the index every run sees;
• resolves contradictions between entries;
• archives its own outdated entries — with a reason;
• marks a person’s entries that have diverged from the code: the “needs review” mark and an explanation of what exactly diverged. It neither touches nor archives your entries.

The main rule of this pass is written plainly in its role: remove what provably contradicts the current code; do not remove what you simply do not recognise. Nobody will restore lost knowledge, whereas you can remove something superfluous in one move.

The last step of a pass at a task boundary is archiving the task scope: everything written about this task and not moved to the project goes to the archive with the reason “task completed”. This happens whatever the outcome of the pass, and if passes are turned off — right at the task boundary: a task’s knowledge does not outlive the task.

What you see

The section has a card for the latest pass: which boundary, when, what changed and what the pass cost — tokens and time. The notification centre receives one event per pass, not one per entry. All changes to entries are visible in the audit log as pipeline actions.

An entry the pass marked “needs review” gets a “Reviewed” button: it clears the mark (change permission is required). Editing the entry clears the mark too — the edit is the review.

What it costs

Passes are ordinary model work on your plan: they are charged like any run and appear in the billing history as a separate kind of work — “knowledge”. What a particular pass cost is shown on its card. A pass runs after the work and does not hold it up.

How to turn it off

Passes are turned off by a platform setting — write to us if you do not need them. The model’s writing tools can be turned off separately: then the model keeps reading the base at every stage but writes nothing to it, neither in the course of work nor through passes. Neither touches the base itself: the entries stay, reach the model and are edited as before.