Every AOS mission has an acceptance bar, a written definition of what "done" means before any work begins. This is what keeps the 61 specialists producing real work instead of busy work, and it is the standard QA tests against before anything reaches you. If you read one thing about how AOS guarantees quality, read this.
What acceptance criteria are
Acceptance criteria are the specific, checkable conditions a piece of work must satisfy to count as complete. They are set when the department leads scope the mission, and they are visible on the Mission Control dashboard from the moment work starts.
A good acceptance bar is concrete and testable. Not "improve onboarding" but "Day 1, 7, and 30 emails rewritten, activation measured weekly, deliverability verified above 95 percent, and a before-and-after comparison attached." Vague goals produce vague work. Concrete goals produce work you can check in a minute.
Where they come from
- The founder brief defines the working goal and three non-goals.
- The department lead translates that into acceptance criteria with a named owner and a deadline.
- QA adopts those exact criteria as its test plan, word for word.
Because the same criteria flow from your brief to the builder to QA, nobody gets to quietly redefine success halfway through.
How acceptance is enforced
Work is not "done" because an agent says so. It is done when it passes the four-step review:
- The builder self-reviews against the acceptance bar and fixes its own misses first.
- QA tests against that bar and rejects anything that falls short, sending it back with specifics.
- A department reviewer reads it with fresh eyes for quality and fit.
- Security scans for boundary crossings and risky changes.
Only after all four pass does the artifact land in your Friday founder summary. The evidence trail records each reviewer and their verdict, so you can always see why something was accepted, not just that it was.
What a rejection looks like
When QA rejects work, it does not silently retry forever. It records the gap, returns the work to the builder, and the loop runs again. If something keeps failing, it surfaces as a blocker in your summary instead of burning tokens in a circle. You see the stuck point rather than a mystery.
Why non-goals matter
The three non-goals in every brief are as important as the goal. They stop scope creep, keep token spend predictable, and make the acceptance bar honest. The team is graded on the thing you actually asked for, not a sprawling reinterpretation of it. If you find yourself wanting to add a fourth goal mid-mission, that is usually a sign it should be its own mission with its own bar.
How to write a good acceptance bar yourself
You do not have to, the department leads will, but if you want tighter control: state the deliverable, the measurable outcome, the format you want it delivered in, and what you explicitly do not want touched. The more specific you are, the less back-and-forth, and the closer the first draft lands to what you pictured.