Read-only review
Use the minimum practical access route that allows the agreed surfaces to be assessed without expanding privileges unnecessarily.
Trust & Access
Know the boundary before anything sensitive is handed over.
Statepath should feel safer because the working boundary is explicit: agreed surfaces only, minimum practical access, read-only where possible, careful AI-use rules, and clean closeout.
Access model
The safest route is the minimum route that still allows a truthful answer.
Statepath is not built around asking for the broadest access first. The default is to stay narrow, explicit, and proportionate.
Shared personal credentials
Temporary or scoped accounts are preferred to broad personal logins, especially where a safer route already exists.
Exact surface list
Repos, docs, folders, dashboards, and automations should be named explicitly before review begins.
No broad first ask
The route should not quietly widen into "everything you have" when a narrower agreed slice is enough to tell the truth.
Default minimum-access ladder: start with the named documents, exports, and screenshots already available; move to read-only repo or dashboard access only if the agreed surfaces require it; use temporary scoped access only when a narrower route cannot answer the question truthfully.
Boundary references
The public route points to the right surface for privacy, terms, and support questions.
The seven-page route stays compact on purpose. This page carries the public handling boundary, while the linked pages carry the matching scope and contact surfaces.
Privacy & retention
See how material is narrowed, retained only as needed, and removed at closeout.
Use the closeout section on this page when the question is data handling, temporary access removal, or what happens after delivery.
Jump to privacy & retention Terms & scope boundarySee what the audit includes, what it does not include, and where the first-step commercial boundary stops.
Use Offer when the question is engagement shape, included work, follow-through limits, or what is intentionally not being smuggled into the first step.
Open Offer boundary Support / contact routeUse the fit-check route or direct email before assuming any broader support relationship.
Statepath is not an always-on support retainer by default. Start with the bounded fit-check route and the minimum context needed to judge the next step.
Open Start HereAgreed-surface boundary
The route should be scoped before access starts, not after the fact.
This is how Statepath stays bounded and legible instead of drifting into open-ended investigation by inertia.
- the exact repo, docs, folders, dashboards, or automations in scope
- the minimum access route needed to review those surfaces
- what sits outside the first-step audit boundary
- whether a closeout call or follow-through note is actually included
- open-ended trawling across unrelated systems
- unbounded export dumps when a narrower sample would do
- always-on support access
- silent scope expansion into implementation or rescue work
Before work starts, the exact in-scope repos, docs, dashboards, folders, and automations should be named explicitly enough that neither side is guessing what Statepath is allowed to use.
AI-assisted work boundary
AI may support the work, but it does not cancel the trust rules.
The operating rule is straightforward: AI can help with organisation, drafting, analysis structure, and synthesis, but sensitive material stays under explicit handling discipline.
- organisation and drafting support
- analysis structure and synthesis support
- human-reviewed delivery-pack preparation
- bounded internal workflow assistance
- client secrets or credentials
- private code
- sensitive personal data
- confidential commercial material
AI output is not treated as truth by itself. Human judgment controls the final pack, and client-confidential material stays inside the agreed handling rules.
What not to send early
Narrow the first contact before the material widens.
The safest first step is a fit note, not a casual dump of files, passwords, or sensitive exports.
- credentials in plain email
- private keys or secret tokens unless clearly necessary
- sensitive personal data outside the agreed scope
- large unrelated exports when a narrower sample would do
- stop widening use of it
- decide whether it is actually in scope
- narrow, delete, or return it if it is not needed
- record the issue if it materially changes the trust posture
Privacy, retention, and closeout posture
The route should end as cleanly as it began.
Operational maturity includes how access is removed, how material is narrowed, and how the boundary stays traceable after the delivery is done.
Keep the scope record explicit
Track the exact in-scope surfaces and the access route that was actually granted.
Remove temporary access
Close temporary accounts and remove permissions when the bounded work ends.
Narrow retention deliberately
Do not keep client material longer than needed for the stated purpose; if retention is needed, keep the reason explicit.
Leave a traceable boundary
After closeout, it should still be obvious what was reviewed, what was returned, and what was removed.
Next step
If the trust boundary feels right, the next move is fit and scope — not early access sprawl.
Use the linked pages to move from trust to qualification and then into the defined review route.
Request a fit check without sending a large package first.
Send the project, the confusion point, and why the wrong next move matters before any sensitive handover starts.
Open Start Here
See the pack shape that comes back.
Review the anatomy of the Truth Audit + Next Route Pack before deciding whether the route fits.
Open Sample Output
Read how the audit actually runs.
See the scope-lock, access, review, and delivery sequence that keeps the route finite.
Open Process