This framework was generated using the Framework Builder methodology. It is the worked example from the five-day "five layers" series: one framework, built one layer at a time. It demonstrates the five-layer DNA architecture applied to delegating work, to a person or to an AI agent.
Principle 1: A delegation fails at the brief, not the execution. When delegated work comes back wrong, the instinct is to blame the executor. Most of the time the brief was underspecified and the executor filled the gap with a guess. Fix the brief and the execution problem usually disappears.
Principle 2: The brief's only job is to transfer the context the executor cannot see. You are holding context the other party does not have: the goal behind the goal, the constraint that is obvious to you, the landmine you already stepped on. The brief carries exactly that load-bearing context across the gap. Everything else is noise that buries the signal.
Principle 3: Ambiguity gets resolved somewhere. Every decision the brief leaves open, the executor will close, on their own judgment, out of your sight. If the decision matters, the brief decides it. An unspecified load-bearing choice is a coin flip you chose not to watch.
Principle 4: A brief is a contract, not a wish. It states what done looks like, what is out of scope, and how the result will be checked. Without those three, you cannot tell a real success from a plausible failure, and you will accept the plausible one because it looks finished.
Step 1: State the goal in one sentence, the outcome and not the activity. "Write three onboarding emails" is an activity. "Get a new client to their first quick win within 48 hours" is an outcome. If you cannot say the outcome in a sentence, you are not ready to delegate it yet.
Step 2: Give only the load-bearing context. The two to five facts the executor needs and cannot infer. The deadline that is real, the tool they must use, the thing that broke last time. Cut everything that is background. A brief that includes everything communicates nothing.
Step 3: Name the constraints and the out-of-scope. What must hold (budget, tools, do-not-touch files, voice rules) and, just as important, what NOT to do. The out-of-scope line prevents more failure than the in-scope list defines, because confident work in the wrong direction is the most expensive mistake.
Step 4: Define done. The deliverable, its format, and the success criteria the executor can check themselves against before they hand it back. "Done" is not "you tried." It is a specific, checkable state.
Step 5: Pre-decide the judgment calls. List the forks you can foresee and make the call, or write explicitly "use your judgment here." Do not leave a load-bearing decision implicit and then be surprised by which way it went.
Step 6: Specify verification. Name the one check that proves the work succeeded: the test that passes, the page that loads, the number that reconciles. A brief that says how to prove it worked turns the executor into their own first reviewer.
Multiplier 1: Template the brief structure once. Goal, context, constraints, out-of-scope, definition of done, judgment calls, verification. Templating the structure turns every delegation from a blank page into a fill-in-the-blanks, which cuts setup time and raises the floor on quality even when you are rushed.
Multiplier 2: One explicit "do NOT do X" line. The single highest-leverage sentence in most briefs is the one that rules out the expensive wrong path. It costs you five seconds and saves the executor from confidently building the wrong thing.
Multiplier 3: Pre-decided judgment calls collapse the back-and-forth. Every fork you decide up front is a clarifying message that never has to happen. Briefs that pre-decide the foreseeable choices come back in one pass instead of three.
Multiplier 4: The verification line makes the brief self-checking. When the brief names the proof, the executor catches their own miss before it reaches you. You stop being the error detector and start being the approver.
Positive indicators:
- The work comes back without a clarifying round-trip (the brief answered the questions before they were asked).
- The output matches the stated outcome without you re-explaining the goal.
- The out-of-scope held. Nothing extra got built.
- You can confirm it passed using the brief's own verification step, not a gut feeling.
Failure signals:
- The executor asks a question the brief should have answered. That is a brief defect, not an executor defect. Fix the template.
- The output is plausible but solves the wrong problem. The goal sentence was an activity, not an outcome.
- Scope crept. Work appeared that you did not ask for, which means the out-of-scope line was missing.
- You cannot tell whether it is done without redoing the work yourself. No verification was defined, so the brief never closed.
A framework that does not get used is not a framework. It is a document. Implementation is the layer where most frameworks die, and it answers four questions.
Where does it live. Not philosophically, physically. What folder, what file, what naming convention. If the brief framework cannot be found in under thirty seconds, it is not implemented, it is filed. Pick one location, name it predictably, and put it where the work actually happens.
When does it get loaded. The brief framework gets loaded at the start of any delegation longer than thirty minutes. Below that threshold the overhead does not earn its existence, just delegate it directly. Name the trigger so loading the framework is automatic, not a decision you re-make every time.
Who maintains it. Frameworks decay. Conditions change, edge cases emerge, the methodology needs revision. Name who is responsible for noticing when the framework needs updating, and who is authorized to make the change. A framework with no owner silently goes stale.
How it improves. Every time the brief runs, something is learned. Either it worked and the framework matured, or it did not and the gap gets logged. Specify how those gaps fold back into the next version, so the framework gets sharper with use instead of frozen at version one.
Edge case: delegating to an AI agent vs a person. An agent has no shared history, so the load-bearing context must be fully explicit, an agent will not "know what you meant." A person carries relationship context but also carries assumptions, so the out-of-scope line matters more with people, who are more likely to helpfully expand the work.
Edge case: the brief that is longer than the task. If the brief takes longer to write than the work takes to do, you are below the thirty-minute threshold. Stop briefing and just do it, or delegate it in one sentence.
Common mistake: confusing a document with an implementation. A consultant delivers the framework as a file and hands it off. Three months later it is in a folder nobody opens and the team has reverted to the old way. The methodology has to live in the workflow, loaded at the trigger point and used by someone other than the author, or it was never built. It was only written.
Build your own. Make it run. howtoframework.com