DRYAS

Dryas Workflow Framework

The Dryas Workflow Framework is a target operating model for AI-assisted software delivery. It sets down who decides, who builds, what each AI may touch, what is remembered, when to pay for a stronger model, and what must be true before work merges.

Ready · Free · open source

Read it on GitHub

The problem it solves

Teams that hand real delivery work to AI hit the same failures, whatever tool they use.

  • The AI builds the wrong thing well, because nobody agreed the design first.
  • A task to fix a form also "tidies" three other modules, and parallel AIs overwrite each other.
  • Every call goes to the most expensive model, or every call goes to the cheapest and fails.
  • Each session relearns what failed last week.
  • "Done" turns out not to be done. The tests were never run.
  • An AI installs, deletes or pushes on its own.
  • Nobody knows whether the guardrails are too tight or too loose.

The framework answers each one with a rule that is enforced where it can be, not only asked for.

What it is not: not a plugin, not a prompt pack, not autonomous, and not an organisation-wide AI policy. A person decides the design and has the final say on anything outward-facing. The AIs are fast everywhere else. The scope is software delivery.

Five layers

  1. MemoryWhat was tried, what worked, what failed.
  2. GovernanceWho decides, and what each AI may touch.
  3. ExecutionSmall tasks, kept apart, built test-first.
  4. EscalationA stronger model only when a cheaper one failed.
  5. ReviewNothing merges unverified. A person ships.
Memory
Carries outcomes across sessions, so the same mistake is not paid for twice.
Governance
Keeps each decision with the right party: people for design and outward actions, a cheap judge for narrow questions, a lock for which files may be touched.
Execution
Turns an approved design into small, checkable tasks, done by cheap AIs that cannot collide.
Escalation
Climbs to a stronger model only on evidence of failure, with the reason on record.
Review
Proves the work before it merges, and keeps shipping a human act.

One loop

Layers say what must exist. The loop says in what order work moves through them: Brainstorm, Plan, Judge, Build, Escalate, Review, Ship.

The loopBrainstorm, Plan, Judge, Build, Escalate, Review, Ship, then back to Brainstorm.BrainstormPlanJudgeBuildEscalateReviewShip
  1. Brainstorm. Settle the design with a person before any code is written.
  2. Plan. Split the approved design into small tasks, each with its files and a done check.
  3. Judge. A small model answers narrow questions so the big model is called less.
  4. Build. Each task is built test-first, in its own isolated copy of the project.
  5. Escalate. A task that fails climbs to a stronger model, with the reason logged.
  6. Review. The diff is reviewed and the tests are run before anything merges.
  7. Ship. A person approves the merge, and the outcome is remembered.

A single-file fix may skip Plan, Judge and Build. It never skips Review, and it never skips the design approval when the design changes (WF-2, WF-4).

Who decides

Orchestrator
The lead AI. Brainstorms with you, plans, hands out tasks and pulls the results together. It decides when the judge is unsure.
Judge
A small, fast model that answers narrow yes, no or pick-one questions. It never writes code or plans (GOV-6).
Builders
Each takes one task, works test-first inside its own files, and reports back in a fixed format (EXE-7).
Lead model
Takes a task a builder could not finish, after the cause of the failure is looked for.
Frontier model
The most capable model. It runs only if the lead model fails too.
A person
Approves the design, approves installs, deletes and settings changes, and decides what goes live (WF-2, GOV-4, GOV-5). Every decision an AI cannot make has a named human owner.

Spend more only when cheaper failed

The escalation ladderA task starts on the economy tier and climbs to cheap, strong and frontier only after failing; after the frontier tier, a person takes over. Every climb is logged with a reason.economyfailed → climb, loggedcheapfailed → climb, loggedstrongfailed → climb, loggedfrontierfailed → climb, loggeda person
  1. Start on economy. Tasks start here.
  2. Then cheap. Takes the task when economy failed.
  3. Then strong. Takes it when cheap failed, once the cause is looked for.
  4. Then frontier. Used only if strong failed too.
  5. Then a person. Takes over with every report, if frontier failed.
  • Tasks start on the cheapest tier, never the top one (ESC-1).
  • Before each climb, the cause of the failure is looked for (ESC-4).
  • Every climb is logged with a reason (ESC-5).
  • After the frontier tier, a person takes over (ESC-6).

The log turns cost into data. It shows how often each climb happens and why, which tells you whether tasks are split too coarsely.

Controls

  • Isolated worktrees. Multi-step work runs in its own copy of the project, one AI session per copy (EXE-1, GOV-3).
  • File scope locks. Every task names the files it may touch, and edits outside them are denied, not just discouraged (GOV-1, GOV-2).
  • Test first. If a task has no failing test, one is written and seen to fail before the fix (EXE-4).
  • Two-stage review. First, does the change match the design and nothing else? Then, is it correct, minimal and readable? (REV-1, REV-2)
  • Verification before merge. The tests are run and seen to pass. A claimed pass that was not observed counts as a failure (REV-3, REV-5).
  • A person ships. AIs commit. Pushing, publishing and releasing stay with a person (GOV-5).

What we measure

The loop already produces the numbers. A metric outside its healthy range is a prompt to look, not an automatic change.

Judge override rate
How often the orchestrator disagrees with the judge. Too high or too low means the judge is trusted wrongly.
Scope-lock denials per task
Repeated denials mean the task's file list in the plan was wrong.
Strong-tier escalation rate
How often cheap models fail and a stronger one is needed.
Frontier use without a strong-tier failure
Should be none. Anything else breaks "stop at the first success".
Cost per merged task
Read as a trend. A rise with flat escalation points to plans that are too coarse.
Review rounds per branch
How many passes a change needs. Many rounds mean problems are caught too late.

What it means for your project

Every project we deliver runs on this framework. You approve the design before anything is built. Nothing merges until it is tested and reviewed, and a person signs off on anything that goes live.

See Sidecraft

Start a project

See it run

Watch sessions move through the loop in a live, simulated view.

FlowObserve live demo