---
title: "How we deliver | Chainfore"
url: https://chainfore.com/how-we-deliver
updated: 2026-10-22
summary: "Every engagement runs through five stages, each with a named output. We separate what the agent says it did from the state of the system it touched, and we verify the second."
---

How we deliver

# Acceptance is agreed before the build.

Every engagement runs through five stages, each with a named output. We separate what the agent says it did from the state of the system it touched, and we verify the second.

- 01 Define. Confirm the workflow owner, the current process, the intended improvement and the acceptance criteria. Compare AI with simpler options before choosing it.

- 02 Bound. Agree data access, allowed tools, actions that need approval, the risk owner and operating constraints. The boundary is written before the build.

- 03 Engineer. Build the integrations, state management, context handling and recovery behaviour the scope requires.

- 04 Verify. Test normal and difficult cases, inspect the resulting state of the systems involved, and document limitations.

- 05 Operate. Agree deployment, support, monitoring, change control and documentation, and deliver an executable handover plan.

Human control stays explicit. Changes to autonomy, tools or model versions trigger proportionate review and testing.

## Four principles behind every dependable enterprise agent

- Reasoning: The model proposes. It does not decide alone. The model plans the next step and proposes an action. The proposal is checked against policy before anything touches a system.

- Context: Only the data this step is allowed to see. Context is assembled per step from sources the user may access. Retrieved material is treated as data, not instruction, and it is dropped once the step ends.

- Execution: Durable steps. Approvals bound to exact actions. Each action is recorded before it runs and can be retried safely. Writes that exceed a threshold wait for an approval tied to that exact action and its expiry.

- Verification: Check the system of record, not the agent's report. After each action, the authoritative system is read and compared with the expected outcome. Deterministic checks run first. Anything they cannot decide goes to a person.

Illustrative trace (invoice reconciliation, a reference example, not a customer deployment):

1. Context: read the invoice and the matching purchase order, within this user's access.

2. Reasoning: propose a match. Amounts and supplier agree; one line item is missing.

3. Verification: check the proposal against policy and the ledger. Variance is under threshold.

4. Execution: post the reconciliation entry as one durable, retryable step.

5. Verification: read the ledger back. Confirm the entry exists exactly once, with the expected amount.

## The engagement path

| Stage | Purpose | Exit criterion |

|---|---|---|

| 1 Discover | Find a funded, measurable problem | A named owner and budget, or a funded question |

| 2 Quantify | Put a value on the problem | Baseline cost, failure cost and value of improvement agreed in writing |

| 3 Build the champion | Find an internal sponsor who will drive the decision | Sponsor commits to a next step and names decision-makers |

| 4 Validate the architecture | Satisfy technical reviewers | Enterprise architect accepts the design, access model and test plan |

| 5 Clear security and risk | Satisfy security, legal and procurement | Security review passed or scoped; contract terms agreed in principle |

| 6 Pilot | Prove the result on real work | Acceptance criteria met; expansion decision taken by the agreed rule |

| 7 Expand | Move to recurring use | Second use case or operations contract signed |

## Qualification rules

- No proposal without a named owner and a budget or funding route.

- No pilot without agreed acceptance criteria and an expansion rule.

- No discount that removes controls. A low price that weakens acceptance or security is declined.

- No production access until data rights and access paths are confirmed in writing.

## Every proposal contains

the business problem and its baseline · the workflow and its boundary · the acceptance criteria · the evaluation plan · the security and data controls · the team and named accountabilities · the timeline and decision gates · the commercial terms · the exit terms

## Questions buyers ask

### What are Chainfore's delivery stages?

Define, Bound, Engineer, Verify, Operate. Each stage has a named output, and acceptance criteria are agreed before the build.

### How does Chainfore verify what an agent did?

We separate what the agent says it did from the state of the system it touched, and we verify the second: after each action, the authoritative system is read and compared with the expected outcome.

### When does Chainfore decline to write a proposal?

When there is no named owner and no budget or funding route. A low price that weakens acceptance or security is also declined.

## Start with one workflow.

Tell us the process, the cost of failure and the systems involved. We will respond with a proposed first step.

Contact: https://chainfore.com/contact