How Tioga AI delivers
A client-safe excerpt of Tioga's internal delivery methodology — the same standard Tioga's own AI-operations estate runs under internally, with the process detail specific to that internal estate trimmed out.
Philosophy
How Tioga builds is what Tioga sells, and that is an operating fact, not a claim. Tioga's own delivery estate — the AI automation that runs Tioga's day-to-day operations — runs under propose-and-approve, with capability-absence and runtime deny lists ranked above documentation as enforcement, read-only agent types, root-originated delegation, and scheduled verification of what its own automations claim against what they actually produced. A prospect who asks "do you actually work this way?" can be shown the deny lists, the agent-type definitions, the verification jobs, and Tioga's own dated incident records — real, found-and-fixed gaps in Tioga's own infrastructure, not a single curated write-up.
Every client engagement below is built to be executed under that same discipline going forward: Tioga sells one thing in fifteen shapes — the connection between agent behavior, governance evidence, and the enterprise transaction itself. An assessment sells that connection as a map. A pilot or write-path build sells it as running, evidenced software. A governance program sells it as a control system with an audit trail. A retainer sells it as a standing watch. Every offer has the same job: produce that connection, with evidence a control owner can inspect.
In practice: Tioga writes the spec, scoped sub-agents do bounded work under least-privilege grants, a human gate sits in front of anything that touches a client system, and a reconciliation pass runs on schedule.
Evidence over assertion, applied to Tioga first: a control you cannot produce evidence for is not a control. Tioga has no client case studies and does not manufacture composite ones that read as real. It offers instead a bounded fixed-fee sprint, a working prototype the prospect can break, explicit go/no-go gates, and a methodology the prospect can read before they read a price. Every phase below ends with an artifact, and the artifact is the exit criterion. "We are confident" is never a gate condition; "here is the agreement report, signed by your controller" is.
Every engagement starts with the same 5-day, $5,000 Discovery Sprint, and a no-go finding out of that sprint is a first-class deliverable, not a failed sale. The client keeps all work product at every gate whether or not they continue. Tioga is never a required runtime dependency: production credentials, repositories, logs, and deployment assets stay under the client's control from the first day, and the handover phase exists to prove that, not merely promise it. Fixed fees have teeth in both directions: named deliverables, named exclusions, objective acceptance criteria, a capped change-order mechanism, and milestone payments tied to accepted outputs.
Tioga is a solo practice by design, not by apology. One person scopes, engineers, maps governance, and produces evidence — the promise ("no handoff to a junior team") is also the constraint the methodology below is built to make workable at scale.
The engagement lifecycle
Every engagement moves through the same stages. Some offers compress or skip a sub-stage, but the decision points are universal: you never move to the next stage without a named artifact in hand and a decision only you make.
You decide: worth a Sprint?
You decide: Go / No-Go / Redirect
You decide: proceed
Milestone-by-milestone acceptance, then cutover
You decide: accept
Handover, proven not promised
You decide, every period
Phase 0 — Do we even talk?
An inbound contact resolves within five business days into one of three outcomes: a Discovery Sprint order, a polite disqualification, or a logged candidate need that no current offer covers. A single 30-45 minute triage call establishes what the pain actually is (automation, an agent that needs to reach a system of record, or answering for AI already in production), what made it urgent now, who signs and who has to be satisfied the result is controlled, which system of record is in play, and how far along the client already is. That produces a starting hypothesis for which offer fits — the Discovery Sprint's job is then to confirm or overturn it. A Discovery Sprint that ends in "you asked for a pilot; the honest answer is a governance readiness assessment first" is a success, and the $5,000 fee credits toward whichever offer the client actually proceeds with.
Tioga declines at triage, with a written reason, when the prospect wants staff augmentation rather than an outcome; requires a raw database write path as the deliverable (Tioga always executes through the application's own logic layer, never a direct database write); requires Tioga to hold production credentials or act as a runtime dependency after handover; requires a reference-customer list as a precondition to paid work; requires a 24/7 SLA a solo practice can't honestly make; or can't fund the Discovery Sprint. A declined prospect isn't a failed lead — it's evidence of where the offer boundary sits.
Phase 1 — Prove it before you buy it
In five working days: one prioritized use case, a current-state system and control map, the key risks and integration constraints, a proposed architecture with control points, measurable pilot success criteria, a fixed-fee pilot plan, and a working prototype — or an explicit, reasoned no-go finding. Everything in the eventual proposal traces back to this report.
This requires read-only sandbox access provisioned before day one — a real ask most mid-market IT groups need more than a week's notice for. If you're not yet sure you have a real, provisionable candidate use case, or can't clear that access fast enough, the one-day AI Fit Check answers that question first, for less than a third of the cost, before either side commits this Sprint's full week.
For a prospect who already has that access lined up, this is where every full engagement starts, including governance-only ones. A governance assessment without a system and control map is a questionnaire; an ISO 42001 sprint scoped without knowing which agents exist and who owns them gets re-scoped in month two. For pure governance offers the "prototype" is a governance artifact rather than code, but it's still a working demonstration, not a slide.
Over the five days: access is provisioned read-only, scoped, and time-boxed. Interviews run with the process owner, the systems owner, the control owner, and the sponsor. A current-state system and control map is built, showing where evidence already exists and where it's missing. Three to five candidate use cases are scored on value, feasibility, blast radius, and controllability — a high-value, uncontrollable use case is not a candidate for a first pilot. One use case is selected with the sponsor, the control points are designed against the client's real approval matrix, and prototype build starts. The prototype is checked against the original plan, risks are written up as a register rather than a paragraph, and pilot success criteria are written as measurements a controller can verify — agreement rate in shadow mode, cycle time, exception rate, evidence completeness — never as adjectives. A no-go analysis is written down explicitly even when the answer is go. Day five is a single readout session with the sponsor and control owner present: the Discovery Report is walked through, the prototype is demonstrated live and recorded, and a fixed-fee pilot plan is presented with named deliverables, exclusions, acceptance criteria, and price. The client leaves with everything.
What's produced: a Discovery Report with seven required sections in order — the prioritized use case and why it beat the alternatives; current-state system and control map; key risks and integration constraints; proposed architecture and control points, including the permission ladder and delegation structure; measurable pilot success criteria; the fixed-fee pilot plan; and the no-go analysis and finding. Plus the prototype and a recorded demo.
- Go. Proceed to Phase 2 on the offer the Discovery Report recommends. The $5,000 credits against the full engagement price.
- Redirect. Proceed, but on a different offer than the triage hypothesis. Same credit rule.
- No-go. Either Tioga's own finding or the client's decision. The client keeps every artifact. There is no obligation to continue and Tioga does not ask for one.
The credit is valid for 60 days from the readout; beyond that, a short re-validation precedes any full engagement rather than assuming the report's state still holds.
Phase 2 — What you're actually signing
The Discovery Report converts into a signed Statement of Work with fixed-fee terms that have teeth, without re-scoping anything Discovery already settled. Every proposal section traces to a named source: the executive summary comes from the Discovery Report's use case and finding, in the client's own words from the interviews; the problem framing comes from the client's own stated trigger and the map's actual gaps — never a generic market statistic standing in for the client's own situation; what's delivered, timeline, and investment all trace directly to the pilot plan and offer pricing; the approach section states how Tioga's three delivery standards apply to this specific engagement.
The Statement of Work binds what the proposal describes, and carries at minimum: deliverables named individually, each with acceptance criteria stated as an observable condition ("client satisfaction" is never an acceptance criterion); exclusions named individually, including what Discovery surfaced and consciously deferred; milestone payments tied to accepted outputs, not elapsed time; a capped change-order mechanism — changes are proposed in writing, priced from a rate card, and capped as a percentage of the fixed fee beyond which the engagement is re-scoped rather than extended; go/no-go language at every milestone gate, with the client owing only for accepted milestones and keeping all work product; a continuity clause stating Tioga is not a runtime dependency — credentials, repositories, logs, and deployment assets are the client's, and Tioga's access is enumerated and revoked at handover.
Phase 3 — The work itself
Tioga builds or assesses what the Statement of Work names, under three delivery standards, with a written weekly status and milestone gates the client can stop at.
Kickoff presents the milestone map, the status cadence, a decision log and risk register kept for the life of the engagement, named approvers for every higher-risk action, the shadow-window definition, the reconciliation-control definition, and — honestly, for a solo practice — the escalation path: Tioga, by email, promptly. A delivery runbook is delivered in draft at kickoff and finalized by the first milestone; it's the document a client engineer would use to understand, and if necessary take over, the build.
Delivery runs as specified increments, each following the same loop Tioga uses on its own estate: a written spec for what changes and what proves it; scoped, typed sub-agents (reader, builder, tester) working under least-privilege grants with no nested delegation; a build step in the client's own repository or a Tioga-held one transferred at handover; a verification step where a reconciliation pass compares what was reported against what actually exists, every increment, not only when something looks wrong; and a human review and approval gate in front of anything that touches a client system.
The three delivery standards, applied concretely:
- Capability, not instruction. Applied at design, before any code. Every agent in the delivered system, every tool it holds, every tool it was deliberately not given, and the permission tier of each action it can take is documented. If an agent could take an action whose misuse would be unacceptable, the tool is removed — not the prompt amended.
- Shadow mode before cutover. Applied before any production touch. A shadow-mode plan defines, before the window starts: the traffic the agent will see, the agreement metric and its threshold, the minimum window length, and what happens on disagreement. Cutover is gated on a signed shadow-agreement report showing the threshold was met — never on the calendar, never on confidence.
- Verification as an unconditional scheduled control. Applied from the first day of the shadow window and never turned off. What the agent claims is compared, on a fixed cadence, against ground truth in the system of record, with a delivered alert — not just a logged one — on any divergence. This control is part of the delivered system, not part of Tioga's project management, and keeps running after handover.
A weekly written status goes to the sponsor and control owner: milestones planned versus actual, decisions taken, risks that changed, evidence produced, and anything slipping, stated honestly. Each milestone is an acceptance event — the named deliverable is tested against its acceptance criteria with the control owner present where it touches a control, and accepted or returned in writing; payment follows acceptance. The client may stop at any milestone with no further obligation.
Phase 4 — Show me it's true
Tioga assembles, for the client's control owners and auditors, the evidence that what was delivered is what was specified, that it behaves as its controls say, and that its controls map to the frameworks the client answers to. The evidence pack is compiled from a ledger that has been accumulating since kickoff — not written at the end. Acceptance is demonstrated live in front of the control owner: the positive cases (the agent does the work), the boundary cases (a lower-autonomy action stops and waits; a human-owned action is not available to the agent at all, demonstrated by showing the tool grant, not by asking the agent to refuse), and the failure cases (the reconciliation control catches an injected divergence; the rollback path works). The failure demonstration is required because it's the part a buyer can't otherwise verify.
Each control in the delivered system is mapped to the applicable framework language — NIST AI RMF, ISO 42001, EU AI Act, or US state law where the client is in scope — as a table naming the control, the evidence artifact that proves it, and the framework reference. A control with no evidence artifact isn't listed as a control; it's listed as a gap.
Phase 5 — Nothing depends on one person after this
Tioga proves, rather than promises, that it is not a runtime dependency and that the client can operate, change, and audit what was delivered without Tioga. Every access Tioga was granted is revoked by the client with Tioga watching, and each revocation is recorded. Repositories are confirmed under client ownership. The reconciliation control is confirmed running under a client-owned schedule with a client-owned alert destination. Knowledge transfer runs as working sessions against the runbook — the client engineer performs a change; the client control owner reads a reconciliation log and an evidence record. Any client material still in Tioga's environment is scheduled for deletion at the end of the post-delivery clarification window.
Phase 6 — Standing coverage, renewed on your terms
Three offers are ongoing: ERP Modernization Advisory, Fractional AI Governance Officer, and Standing Watch Retainer. They still enter through Phases 0-2 — the Discovery Sprint scopes the first period's priorities and produces the baseline the retainer is measured against. Delivery is then periodic rather than milestone-shaped: Standing Watch runs a weekly automated watch, a monthly human review, and a quarterly evidence pack mapped to NIST AI RMF, ISO 42001, and the EU AI Act; Fractional AI Governance Officer and ERP Modernization Advisory run on a monthly cycle with a monthly written review and a quarterly evidence or decision pack, using the same one-page structure as the weekly status report so the client never sees two report formats.
Verification stays unconditional on a retainer — the weekly run happens whether or not anything looks wrong — and any proposed change to a control shadows first, the same as during delivery. Each period ends with an explicit continue/stop decision the client can take at any period end, and a retainer exit follows the same handover process as any other engagement in full. Nothing about "ongoing" exempts it.
Governance and evidence discipline
Every engagement, regardless of offer, produces evidence against the three delivery standards at every phase. Where an offer has no built agent — a pure governance assessment — the standards still apply to Tioga's own delivery process, and the client-facing artifacts describe the client's agents rather than Tioga's.
The evidence ledger. Opened at first contact, append-only, one row per artifact or event: date, what, where it lives, who produced it, who verified it, who signed it. This is the backbone of the evidence pack, and it's also the artifact Tioga would hand to its own auditor, or to a client who asks "show me how you worked" — it has to be able to bear that reading.
What counts as evidence. An artifact only counts as evidence in a Tioga engagement if it is attributable (names a human or an agent type, never "the system"); timestamped at creation and immutable or versioned thereafter; reproducible (a control owner can re-run the check and get the same result, without Tioga); located (a path, a system, an owner, a retention period); and tied to a framework reference where one applies, or listed as a gap where it doesn't yet have one. Anything that fails one of these is recorded, but as a claim — not as evidence.
Self-application. This is the "consistency is an operating fact" claim made checkable — each row below is something a prospect can be shown, mapped to the client-facing artifact that embodies the same discipline:
| What Tioga runs on its own estate | What the client gets |
|---|---|
| Runtime deny lists on production-affecting actions in Tioga's own agent configuration | The Tool-Grant Matrix's “tool-enforced” column |
| Read-only agent types with no write or delegation capability | Typed sub-agents in every engagement, documented in the delegation-topology deliverable |
| Root-originated delegation; no nested sub-agent spawning | The delegation-topology deliverable |
| Human approval required on any externally visible action (publishing, sending, deploying) | The Ask-First permission tier; the propose-and-approve layer in Standing Watch |
| Scheduled verification of Tioga's own automation outputs against what they actually produced, with delivered alerts | The Reconciliation Control deliverable |
| A kept, cited write-up of Tioga's own first-party delegation incident | The evidence behind the capability-not-instruction standard; the honesty statement in Tioga's methodology |
| Engagement-level data handling with named subprocessors, deletion at close, and a plainly stated solo-founder incident posture | The data-handling section of every proposal; the deletion schedule at handover |
What a control owner should be able to ask, and get:
| Question | What answers it |
|---|---|
| What can this agent do, and what has it been deliberately prevented from doing? | The Tool-Grant Matrix |
| Who approves each action it proposes? | The Tool-Grant Matrix, with named identities in the client's own system |
| How do we know it does what we think before it does it for real? | The shadow-mode plan and signed agreement report |
| How do we know, every day, that what it says it did is what it did? | The reconciliation control and its log |
| Which framework clause does each control satisfy, and where is the proof? | The evidence pack |
| What happens when it is wrong, and can you show me? | The acceptance test's failure demonstrations; the runbook's rollback path |
| What do you (Tioga) still have access to? | The access plan, the revocation checklist, the access log |
| How did you work on our material, and who else touched it? | The proposal's data-handling section, the evidence ledger |
This is an excerpt. The full methodology, including practice-specific delivery patterns and Tioga's internal process detail, is available on request.