Scoping starts with a current-state assessment, not a proposal template — a recommendation built on an assumption about your starting point is a recommendation for someone else's problem. Therefore, week one is the current-state assessment itself, and the client sees it before any solution is proposed.

We'd rather tell a client "not yet, here's what has to be true first" than take on work we don't have the evidence or capacity to do well. Therefore, an engagement that starts before that evidence exists doesn't start — sometimes the first real decision we make is that we're not ready to begin.

Every engagement has a named, accountable owner — on our side and, where relevant, on the client's. Therefore, before the first deliverable exists, there's a name attached to the outcome, not a team.

No assumption about a technical constraint proceeds into a funded build without being tested or explicitly flagged as untested. Therefore, we test or flag before we build on top of it — a false assumption caught before the build is a rebuild avoided.

Uncertainty isn't only technical. A market assumption, a pricing model, or a demand assumption carries the same risk as an unverified technical constraint. Therefore, we treat a commercial assumption the same way — named, tested where testable, flagged plainly where it isn't — rather than folding it quietly into a business case.

Uncertainty about how a client's own team will actually operate what we build — who owns it, whether the process survives contact with the org chart — is a real risk to the engagement, not a detail for the handoff meeting. Therefore, we ask those questions early, not once the system is already built and the answer is a scramble.

Uncertainty about whether an approach will actually work under real constraints doesn't get resolved by confidence — it gets resolved by testing the riskiest assumption first. Therefore, the highest-uncertainty piece of a build gets attempted before the easy, certain pieces, even though that's the less comfortable order to report progress in.

A verbal agreement in a meeting is a draft, not a decision — it becomes real once it has a stated rationale, a named owner, and a condition under which it gets revisited. Therefore, a decision without a stated reversal trigger isn't treated as finished, on our own work or in what we hand to a client.

Rationale in writing is available to the client, not just held internally. Therefore, decision records live where the client can see them throughout an engagement, not compiled retroactively for a final report when someone asks why a choice was made.

We're precise about the difference between what we know, what we're inferring, and what we're guessing — and we say which is which, in every status update, not only in a final report. Therefore, a status update that would normally say "on track" instead says exactly what's been verified and what hasn't.

We don't pad an update to look more thorough than the week required, and we don't compress a genuinely hard problem into a confident one-liner because that's what's expected. Therefore, some updates are short, and some name a real problem plainly — the format doesn't change to make a difficult week look better than it was.

Increments ship end-to-end or they don't count as shipped — a UI without an API behind it isn't progress a client should be billed confidence for. Therefore, what changes week to week is what's actually running, not what's been sketched.

Scope changes get documented with the same rigor as the original scope; silent scope drift is a governance failure, not a normal cost of doing business. Therefore, a changed scope shows up as a written, dated change with a reason attached, not a difference someone notices later between the plan and what got built.

A successful engagement is judged by what's true after we've left, not at the moment of handoff. The system runs on the client's own team without needing to call us back, because the documentation and the decision records were written to be read by someone who wasn't in the room — not by us for our own reference.

The client's team can point to a specific, written reason for the choices that shaped what got built, and can extend the work themselves the next time the problem changes shape, without waiting on us to remember why a particular call was made. Governance carries on the same way after we're gone as it did while we were there — reviewed at its stated points, not quietly abandoned once the engagement ends. The clearest sign an engagement worked is a client who feels no anxiety about that continuity, not a client who feels obligated to keep us around.