01 scope
Define the lane
Write what is allowed, what is out of bounds, what the operator must decide, and what would make the run unsafe.
The shape
The diagram is deliberately simple. Real work bounces backward whenever evidence contradicts the plan. That bounce is not failure; it is the safety mechanism.
01
ScopeAllowed lane, red lines, operator gates.02
OrientCurrent docs, source, tests, status.03
MapSurfaces, risks, owners, next moves.04
DraftLocal artifact before public action.05
VerifyTry to break the claim.06
ShipOnly the approved external slice.07
JournalRecord signal, skip noise.08
ReviewTurn mistakes into better rails.Loopback rule: failed verification jumps back to scope, map, or draft.
A stale claim becomes a lead. A missing gate becomes a decision. A surprise risk becomes a new
boundary.
The full loop
Each pass tries to end with a durable artifact. If something cannot be verified, it gets downgraded instead of polished into a better-sounding story.
02 orient
Read source first
Use repo docs, boards, tests, CI, public metadata, and current git status before trusting memory or summaries.
03 map
Turn chaos into surfaces
List projects, risks, owners, missing rails, and proof paths. Give every surface a role and a next action.
04 build
Draft locally
Create reviewer-safe materials, patch plans, claim cards, checklists, and snippets before touching public systems.
05 verify
Try to break the claim
Run safe checks, inspect tests, compare docs to code, and downgrade anything unsupported.
06 ship
Gate external change
Only edit repos, publish pages, commit, push, deploy, or touch billing when that exact slice is approved.
07 journal
Leave a trail
Append concise run notes only when something meaningful changed. Idle runs stay quiet.
08 review
Fold lessons back in
Every false positive, stale metric, blocker, and good pattern becomes a better rail for the next run.
Three operating modes
The system should not wear the same armor for every task. The strictness changes with risk, audience, and whether the output can affect other people.
Exploration
Use lightweight notes, fast sketches, and disposable probes. No claim cards unless a result is about to be reused, published, or sent outside the room.
Shipping
Turn on the gates: source check, caveat, claim state, validation command, review surface, and journal entry. Public wording must be weaker than the evidence, never stronger.
Security / billing
Default to strict. Scope comes first, secrets stay out, external actions need approval, and scanner or model output remains a lead until independently checked.
North-star rules
A
Authorization before action.
Security work starts with scope. If the boundary is unclear, the answer is no or pause.
Security work starts with scope. If the boundary is unclear, the answer is no or pause.
B
Evidence before claims.
A link, test, command, receipt, artifact, or operator-approved status must back the words.
A link, test, command, receipt, artifact, or operator-approved status must back the words.
C
Local before public.
Draft privately, verify locally, then publish only after the wording is safe.
Draft privately, verify locally, then publish only after the wording is safe.
D
Lead is not proof.
Scanner output, model output, and intuition are starting signals. They are not findings until checked.
Scanner output, model output, and intuition are starting signals. They are not findings until checked.
E
Honest no counts.
An unavailable gate is n/a, not pass. A failed check is useful signal, not embarrassment.
An unavailable gate is n/a, not pass. A failed check is useful signal, not embarrassment.
What never goes public
This page is intentionally high level. The method is copyable; sensitive material is not.
- Secrets, keys, tokens, cookies, or browser-store data
- Private exploit steps or payloads
- Unpatched target names unless already public and approved
- Private maintainer messages
- Stripe keys or live billing configuration
- Claims of CVE, severity, payout, or acceptance without public evidence
Public-safe translation: say the class, the control, the status bucket, and the public reference. Leave the private mechanics out.
A real public-safe pass
A concrete example, stripped of private material: refining this page after a blunt outside review called it too linear, too text-heavy, and too easy to turn into process theater.
Scope
Allowed: improve public copy and structure. Out: secrets, private exploit details, live credential surfaces, or invented proof.
Orient
Read the live page, source file, current git state, and the critique. Treat the critique as input, not authority.
Map
Find the gaps: no diagram, no iteration warning, no exploration mode, no wrong-tool section, no example run.
Draft
Add a visual flow, loopback rule, operating modes, example walkthrough, and failure boundaries.
Verify
Parse the HTML, check mobile constraints, and search for stale or overstrong public claims before publishing.
Ship
If approved, deploy only the scoped website files from a clean remote base so unrelated local commits do not leak into production.
Journal
Record what changed, what was verified, what remains gated, and any collision risk.
Two evidence shapes
Different work needs different proof, but the public pattern stays the same: define the boundary, test a clean control and a meaningful refusal, then say what the result cannot establish.
Authorization reference fixture
Scope: synthetic, loopback-only MCP-shaped tool calls. Check: an exactly scoped read beside bearer, resource, audience, scope, session, and token-handling refusals.
Public artifact: a self-contained test, evidence snapshot, and explicit non-conformance boundary.
What it proves: the stated fixture mechanics reproduce. What it does not: a production-server assessment or full protocol conformance.
Signed-agent replay fixture
Scope: an operator-owned local reference with synthetic identities and a persisted replay marker. Check: a first valid operation, a valid replay, malformed state, and interrupted-state refusal paths.
Public artifact: local tests, a sanitized scenario receipt, and a recovery limitation statement.
What it proves: the bounded local cases reproduce. What it does not: distributed coordination, power-loss recovery, or production replay safety.
The artifact stack
The work is organized around artifacts that outlive the session. Each artifact has a job, an evidence level, and a publication boundary.
| Artifact | Purpose | Public-safe version |
|---|---|---|
| Board | Source of truth for lanes, blockers, and approval gates. | High-level roadmap and status. |
| Decision log | Operator choices that change what can be edited, named, or published. | Only the approved result, not private deliberation. |
| Claim card | One claim, one evidence bundle, one caveat list. | Short sourced statement with links. |
| Run journal | Append-only notes for meaningful progress and blockers. | Summarized changelog. |
| Security ledger | Disclosure history without exploit detail. | Date, class, status, public reference. |
| Patch plan | Safe route from draft to external edit. | Scope, files, validation, approval gate. |
| Receipt or test | Proof that a result can be reproduced or inspected. | Command, CI artifact, run id, or hash. |
Daily operating rhythm
1
Open the board.
Find the active lane and the current operator gates.
Find the active lane and the current operator gates.
2
Check the tree.
Know what is clean, dirty, external, and user-owned before editing.
Know what is clean, dirty, external, and user-owned before editing.
3
Make the smallest useful move.
Prefer one durable artifact over a dozen vague ideas.
Prefer one durable artifact over a dozen vague ideas.
4
Verify or downgrade.
If a claim cannot be checked, mark it as a lead, candidate, or blocked.
If a claim cannot be checked, mark it as a lead, candidate, or blocked.
5
Record only signal.
Append the journal when progress happened. Skip noise.
Append the journal when progress happened. Skip noise.
False-positive response
When something fake, stale, or overconfident appears, the workflow does not panic. It diagnoses.
1. Freeze the claim.
2. Locate the source of truth.
3. Classify the failure.
4. Verify with the smallest safe check.
5. Downgrade, patch the draft, or add a blocker.
6. Continue quietly unless operator input is needed.Rule: a beautiful claim with no proof becomes a lead, not a headline.
When this is the wrong tool
This workflow is not meant to turn every thought into a compliance exercise. Use something lighter when the cost of being wrong is low.
- Early creative brainstorming where speed matters more than correctness
- Disposable prototypes that will never be cited or shipped
- Private notes that make no public or security-sensitive claim
- Exploration where the only output is "learn what to inspect next"
- Emergency containment where immediate safety beats perfect documentation
Minimum rule still applies: do not expose secrets, private target details,
or unverified public claims just because the mode is lighter.
Anti-bureaucracy rails
The workflow fails if it becomes a shrine to itself. These checks keep the system useful.
1
If the artifact takes longer than the check, shrink it.
A claim card can be five lines when the claim is simple.
A claim card can be five lines when the claim is simple.
2
If two artifacts repeat each other, merge the truth.
The board tracks state; the journal records completed facts; drafts should not pretend to be either.
The board tracks state; the journal records completed facts; drafts should not pretend to be either.
3
If nothing leaves the room, keep it light.
The heavy gate starts when a claim becomes reusable, public, security-sensitive, or costly.
The heavy gate starts when a claim becomes reusable, public, security-sensitive, or costly.
4
If the process blocks obvious work, inspect the process.
The point is better output, not better paperwork.
The point is better output, not better paperwork.
Copy this system
This is the portable version. It works for security research, AI evaluation, product building, writing, grants, games, or any other complex loop where hallucination and drift can ruin the output.
- Create a board with lanes, active status, and operator gates.
- Create a decision log for identity, publishing, external edits, and sensitive wording.
- Create an append-only run journal.
- Use claim cards for every public metric or security statement.
- Separate leads, candidates, verified claims, and published claims.
- Never let a scanner or model speak as proof by itself.
- Write patch plans before editing external repos.
- Keep secrets and private exploit details out of public artifacts.
- When blocked, name the next operator decision instead of improvising around it.
- Let the system reward restraint: no fake pass, no fake certainty, no fake urgency.