Applied R&D. Integrated AI systems.

Systems / FF—01

Operating
knowledge.

An illustrative study in connecting organisational knowledge, access boundaries and human decisions.

Reference studyFictional source materialBrowser demonstrator · No live inference
Operating knowledgeSupported answer
The question

Who reviews a new supplier?

Source record

Supplier
onboarding

Revision 02Superseded
Revision 03Current
Access: operations
A supported answer

Operations and procurement.

Operations and procurement must both review a new supplier before the supplier record is activated.

Source: Supplier onboarding · Revision 3

Every action still needs
a person with authority.

Inspect a condition
Follow the decision path +
  1. 2 candidate documents
  2. 2 permitted for operations
  3. 1 current source
  4. Answer supported; action requires a person
Inspect the fictional source data ↗

An answer is only useful if its context holds.

Organisational knowledge rarely arrives as a clean dataset. There are superseded procedures, conflicting copies, restricted material and decisions that belong to particular people. A fluent answer can hide all of that complexity.

This demonstrator makes three conditions inspectable. A current, permitted source supports an answer. Conflicting current copies require a document owner’s decision. A restricted source stays outside the answer. In every case, an action remains with a person who has authority.

The decision before the model.

Separate evidence selection from answer generation. Apply access and revision checks before assembling context. If the relevant sources cannot support a single position, return the uncertainty instead of smoothing it away.

Sometimes the most useful output is a well-explained reason to stop.

The reference shows those checks as deterministic rules. A production system would need to carry the same boundaries through ingestion, retrieval, model calls, tool access, the interface and the operating environment.

What a complete build needs to establish.

  • Whether permissions are preserved from each source system through retrieval and response.
  • How revisions, effective dates and competing authorities are resolved.
  • Which tasks justify a model call, a specialist route or deterministic logic.
  • How failure, uncertainty and human approval are represented in the workflow.
  • What a completed task costs, including retries and review.

What this study establishes—and what remains open.

The local demonstrator checks a small, fictional document set. Its three conditions can be reproduced from the published fixture. It does not connect to business systems, run a language model, prove a retrieval method or measure production performance.

The next engineering step is to evaluate a complete implementation against representative tasks and actual source permissions. The method, results and remaining failures belong alongside the interface.

Inspect the source fixture
Form From / Reference studiesAll systems ↗

A question worth pursuing

Bring us
the hard part.

A capability your organisation needs. A system that needs to work differently. An idea worth finding out about.

Start a conversationHow a programme takes shape →