Perspectives ·

An answer without a source is an opinion.

Grounded answers, human approval and data protection belong in the design, not in the policy binder.

A language model answers with the same fluency whether it knows or not. In conversation that is a curiosity. In a business it is a liability. The status of an invoice, the obligation in a contract and the right to approve a payment are facts with consequences. An answer about any of them is worth exactly as much as the record behind it.

Three design decisions follow from that. Each is cheaper to make at the start than to add afterwards.

Every answer cites its record.

An answer should arrive with the document, the page and the field it came from, so that a reviewer can check it in seconds instead of trusting it. That needs more than a search index. The facts a question depends on are spread across systems: the invoice in the ERP, the contract in a document store, the agreed terms in an email thread. A knowledge graph connects those records, so a citation can be followed from the answer back to its source and across to the records related to it. Where the source is missing, the system should say so rather than fill the gap.

A person approves what matters.

Agents can carry work forward: match an invoice to its purchase order, assemble the papers for a renewal, route a request to the right approver. The line falls at consequence. An action that moves money, creates an obligation or changes a customer's personal data stops for a named person. The agent prepares the action. The person decides. The system records both. This is slower than full automation, and that is deliberate. It is how a business keeps the authority it already assigns to people.

The law is a design input.

The UAE's Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data sets obligations on how personal data is collected, processed and transferred. Sector regulators add their own. Obligations of that kind are easiest to meet as design decisions: which records an agent may read, where data is processed, how long it is kept, and who can see an answer that contains it. Settled at design time, they become access rules and retention settings. Discovered after launch, they become a rebuild. Which obligations apply to a given business is a question for its legal advisers. Our part is to make sure the answer can be built.

None of these decisions is novel on its own. The discipline lies in holding all three at once, from the first prototype onwards, so the system that reaches daily use is one a business can stand behind.

An answer with its source is evidence. Without one, it is an opinion. The difference is built in from the start.

Start here

Bring us the decision you are weighing.

A briefing is a conversation about one process and the systems around it. If there is a fit, we propose a diagnosis or a defined build.