How it works
A methodology layer around the model, with a learning loop behind it.
AuditFellow does not replace the chat your team uses. It attaches a structured methodology to each request at the moment the chat sends it, makes the model reason through it in a fixed order, checks the result against an output contract, and turns your reviewers' corrections into versioned rules. The model writes; the harness decides what a correct answer looks like.
1 · Request-level injection
The harness travels with the message, not with the person
The browser extension intercepts the request the chat sends to its own server and appends the harness: the reasoning core, the catalogue of skills with their output contracts, the global and team rules, and the knowledge files. The model your company already pays for does the writing. Nothing is sent to AuditFellow: the only traffic to us is a daily key check and the pack download. The full harness travels once per conversation; later messages carry a short reminder, and a compact variant fits chats with small context windows.
2 · The reasoning loop
Eight phases before a word of the deliverable is written
Understand the request; inventory the tools the session really has; recall what the conversation already settled; map the request to exactly one skill, with hard isolation so no other methodology leaks into the shape; choose the safest route; ask at most two questions, only for inputs the deliverable cannot exist without; execute under the contract; deliver in the person's channel and language. Any value the organization did not supply, a rating scale, an owner, a target date, is written as N/A. It is never invented.
3 · Skills with output contracts
A skill is a specification, not a prompt
Each skill holds the methodology for one deliverable (a finding, a risk statement, a control, a workpaper, a data strategy, an AI usage document), an output specification with the fields, their order and their labels, and a self-review checklist rendered from that specification. The checklist runs before delivery, and it names the known failure modes explicitly, for instance a "Risk" section where Business Impact and Risk Level belong. Every answer opens with the line "AuditFellow · task", so anyone can see which methodology was applied.
4 · The learning loop
Corrections become rules only after they prove themselves
A reviewer corrects an answer in plain words. A distiller turns the correction into a candidate rule, conceptual rather than a string match. A gate then re-runs a set of requests with and without the rule and scores both against the output specifications; only a rule that raises the score is applied. Rules are versioned with rollback, live in the team layer (encrypted storage we cannot read, or your own endpoint, holding distilled rules only), and reach every key of the organization with the next pack, within a day. Admins and coordinators feed the team layer; auditors keep their corrections on their device.
Every night we run our own prompts through the shipped harness against a model and score the shape of the answers, so a regression in a chat platform or a model update shows up on our side before it reaches your team. Changes are listed on the Updates page inside the app.