1. The system should know where its answers come from
If the source does not support the answer, guessing is not an acceptable substitute.
How we design AI to be controlled, accountable and trustworthy
AI can be useful without being allowed to do everything. We design around approved information, defined boundaries, human ownership, deliberate testing and clear escalation. We reduce risk; we do not promise absolute safety.
Eight principles in plain language
2. Saying ‘I don’t know’ is a feature
The right response may be to clarify, say the information is unavailable, direct to an approved source, escalate or refuse. A system that declines is not a system that failed.
3. Someone must remain accountable
Within your organisation, one named person is accountable for the capability, including its sources, permissions, escalation, problem review and material changes. That is agreed during the governance phase and it is a business decision, not a technical one. If nobody is willing to own it, that is a useful signal about whether it should be built.
4. More capability is not always better
The question is not how much AI can do. It is what this AI should be trusted to do in this business.
5. We test the difficult questions, not just the easy ones
Testing includes missing or contradictory information, unclear requests, attempts to cross boundaries and situations requiring a person.
6. Good AI can still fail on bad or outdated information
Policies, services and source material change. Knowledge maintenance is part of keeping the capability useful.
7. There must be somewhere for the question to go
Escalation defines the person or team, the circumstances, what information is passed and what the user is told when nobody is immediately available.
8. Changes should not quietly bypass the rules
Changes to sources, models, integrations, workflows or scope trigger review and appropriate retesting.
The system should know where its answers come from
Every assistant we build draws on a controlled knowledge source assembled for its agreed purpose. For client work, authoritative production knowledge is approved by the organisation. An initial demonstration may begin with appropriate publicly available or supplied business information, with unverified material identified as an assumption and returned for confirmation before it is treated as authoritative.
AI Architecture Lab may use assessed AI and technology tools to analyse approved client materials, structure knowledge, generate drafts and support testing, deployment and improvement for that client. That processing is part of delivering the service. It does not mean raw material enters an assistant's authoritative knowledge unchanged: uncontrolled or uncertain information is classified, checked and bounded before production use.
How the source is built
1. You nominate
We agree which supplied or appropriate public sources may be assessed for the intended use.
2. We classify
Every item is marked as verified, assumed, or requiring your confirmation. Nothing ambiguous passes silently.
3. You confirm
You confirm, correct or reject each material flagged item before it is treated as authoritative production knowledge.
4. We record exclusions
Every source excluded is recorded with the reason. That record forms part of what you receive.
Narrower coverage, better control
This approach has a real cost and we would rather name it than let you discover it. An assistant built this way covers less ground than one pointed at everything an organisation has ever published. It will encounter questions it cannot answer, and it will encounter them in front of your people.
What you get in exchange is knowing what it is working from. Production answers trace to approved knowledge; demonstration assumptions remain identifiable until confirmed. When an answer is wrong, you can investigate the source or rule and correct it rather than guess at the system.
In a care setting, a rural service, or a public-sector context, we think that is the right side of the trade. If your priority is maximum coverage rather than maximum control, we are probably not the right firm for that piece of work.
Saying ‘I don't know’ is a feature
When a question falls outside the approved source, the intended behaviour is to say so and point the person to someone who can help — not to assemble a plausible answer from general knowledge.
This is designed in rather than hoped for. The rules governing what the assistant must say, what it must refuse, and when it must hand off to a person are written during the design phase, approved by you, and tested before anyone uses it.
A system that declines is not a system that failed. It is the system doing what it was built to do. We would rather an assistant say "I do not have that" a dozen times a day than invent one answer that sounds right.
We do not claim AI cannot produce a wrong answer. Reducing unsupported answers is a design and testing discipline, not a setting that gets switched on. We narrow what the system draws on, write explicit refusal and hand-off rules, test against prompts designed to push past those rules, and record what happened.
What we keep out
- Unnecessary personal information about individuals. Ordinary personal information may be used only where it is reasonably required for an approved use case and appropriate privacy, security and governance controls are in place.
- Highly sensitive health, care or other regulated information unless the use has been specifically assessed and approved with suitable safeguards.
- Passwords, authentication secrets, private API keys, payment-card credentials, banking login credentials and other unnecessary high-risk credentials.
- Unverified material presented as authoritative production knowledge.
- Uncontrolled bulk ingestion of websites, document libraries or third-party material without a defined purpose, rights assessment and review process.
- Material the organisation does not hold the rights to use.
The applicable exclusions and controls are defined for the use case. The principle is data minimisation and controlled processing, not a blanket prohibition on information legitimately required to provide an approved service.
Someone must remain accountable
Professional, clinical, care, legal and financial decisions remain with the people authorised and qualified to make them. Nothing we build decides on your behalf, acts on your behalf, or is positioned as a substitute for a qualified person.
Standard ACOS implementations are not intended to autonomously make significant decisions about employment, credit, insurance, healthcare, legal rights, eligibility for significant services or benefits, or similarly consequential outcomes. A proposed use of that kind requires specific legal, privacy, security and governance assessment, appropriate transparency and accountable human oversight.
Within your organisation, one named person is accountable for the capability, including its sources, permissions, escalation, problem review and material changes. That is agreed during the governance phase and it is a business decision, not a technical one. If nobody is willing to own it, that is a useful signal about whether it should be built.
Our role is to design the boundaries, test them, document them and hand over something your people understand well enough to challenge.
We test the difficult questions, not just the easy ones
Before an assistant reaches anyone, it is tested against a written protocol agreed in advance — not tried out informally until it seems fine.
What testing covers
| Area | What is tested |
|---|---|
| Staying in scope | Whether it answers only from the approved source, and declines when it should. |
| Refusal under pressure | Whether the refusal rules hold when a question is rephrased, pressed, or asked indirectly. |
| Correct routing | Whether people are pointed to the right place, and whether hand-off to a person happens when it should. |
| Required disclosures | Whether statements that must appear in certain answers actually appear, every time. |
Every result is recorded, pass or fail. Failures are recorded as failures, remediated, and retested rather than quietly adjusted. You receive that record — including anything that failed on the way — before your people use the system.
What we will not pretend
- AI is always correct.
- Every task should be automated.
- A demonstration establishes production performance.
- AI replaces accountable human judgement.
- Governance can be added once and forgotten.
- Information quality does not matter.
- A famous platform automatically makes a system appropriate.
Governance is Phase 6. Review is Phase 7.
In our methodology, ACOS, governance is a phase of work with its own outputs rather than a document produced at the end. It establishes accountability, permitted use, monitoring, what happens when the system gets something wrong, how changes are approved, and a written statement of known limitations.
The phase that follows it is Evolve, and it exists because AI capability decays. Policies get updated, services change, experienced people leave, and a system built on last year's information keeps answering confidently from it. Nobody decides to stop maintaining it — it simply stops being anyone's job. Making review a phase is how we try to prevent that.
See the seven phases of ACOSStart with a problem worth controlling properly
Governance is easier to demonstrate than to describe. The Free 30-Day AI Assistant Experience is a structured evaluation built from appropriate public or supplied business information, with assumptions identified and authoritative knowledge confirmed through discovery. The part worth watching is what the assistant declines to do.
Start your free 30-day experience