§How we work
The rules we can be held to
These are the working rules behind our scopes. The commitments for your engagement are the ones written into the scope you approve.
01
Written scope before implementation
The proposed one-page scope states the outcome, systems, boundaries, delivery stages, setup cost and ongoing care. You approve that scope and its fixed quote before the build begins. Later scope changes are discussed and priced before work proceeds.
02
We start from work we know
Each package draws on an operating pattern we use in our own businesses. The written scope identifies what transfers cleanly, what needs adapting, and what is new.
03
Autonomy is earned in stages
Deployments start approval-first: the assistant drafts and prepares, humans approve. Autonomy expands lane by lane — by your decision, against a clean track record, recorded in the scope. Day-one full autonomy is something we refuse to sell.
04
Data duties are part of the design
The scope names why data is needed, where it is processed, which service providers handle it, who may access it, how long records are kept, and the available export and deletion paths. We use service terms that exclude engagement data from training shared models, and record that condition in the scope.
05
The exit is designed at the start
Every scope names the off-boarding deliverables and formats: source material, agreed operating records and configuration owned by you, plus the steps for revoking credentials and closing connections.
06
Limits are written down
Every scope names what the assistant will not do and what remains human: legal, medical and financial judgment, sensitive relationship moments, and decisions for which you retain accountability. If an assistant is the wrong tool, we say so before implementation begins.