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
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.
- 1Context: read the invoice and the matching purchase order, within this user's access.
- 2Reasoning: propose a match. Amounts and supplier agree; one line item is missing.
- 3Verification: check the proposal against policy and the ledger. Variance is under threshold.
- 4Execution: post the reconciliation entry as one durable, retryable step.
- 5Verification: read the ledger back. Confirm the entry exists exactly once, with the expected amount.
A reference example, not a customer deployment or a performance claim.
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
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 →