Living documentCreated 2026-07-28Updated 2026-07-285 min read

Procurement Intelligence

Procurement Intelligence is not a tender-writing assistant. It is an Enterprise Intelligence Layer that helps organisations discover, preserve, and apply their accumulated knowledge while respecting the expertise, judgement, and craft that make them competitive.

This case study documents why the system exists, the constraints that shaped it, and what building it changed about my thinking.

Problem

The visible problem is public procurement: opportunities appear, deadlines are fixed, and responses are expensive to produce.

The real problem is larger.

Most organisations don't know what they already know.

When a procurement opportunity appears, companies typically assemble a temporary team. That team spends days or weeks answering questions the organisation has, in principle, already answered:

Have we done something similar before?
Which department owns this expertise?
Do we satisfy requirement X?
Which regulations apply?
Where is the evidence?
Who wrote the previous proposal?
Which projects demonstrate this capability?

Almost none of this work creates new value. It is organisational archaeology. The knowledge exists, fragmented across documents, emails, SharePoint, Confluence, disconnected systems and people's memories.

The consequences are predictable:

opportunities are missed
responses are inconsistent
expertise remains siloed
the organisation repeatedly solves the same problems

The objective is therefore not to automate proposal writing. It is to reduce the cost of discovering and reasoning about organisational knowledge.

Constraints

Privacy

The company's accumulated knowledge is one of its greatest competitive advantages. It must never become training data for an external provider.

The architecture therefore assumes:

organisational knowledge remains under company control
retrieval happens locally whenever possible
only the minimum required context leaves the organisation
model providers are interchangeable

Accuracy

Generating fluent text is inexpensive. Generating trustworthy answers is not.

Every conclusion must be explainable. Agents reference evidence rather than invent confidence.

Human responsibility

Submitting a proposal is a business decision. The system recommends. Humans approve.

Cost

Not every reasoning step requires a frontier model. Smaller specialised models handle extraction, classification, routing and validation. Expensive reasoning is reserved for genuinely difficult problems.

Architecture

I deliberately do not call this RAG. Retrieval is one capability among many. The system is an Enterprise Intelligence Layer.

flowchart TD
  sources["Tender Sources · Legislation · Regulatory Updates"]
  sources --> ingest["Ingestion Pipeline"]
  ingest --> norm["Normalisation"]
  norm --> index["Knowledge Graph / Index"]
  index --> brain

  brain["<b>Company Brain</b><br/><br/>Projects · Capabilities · Architectures · Policies<br/>Previous Bids · Lessons Learned · Experts · Craft Excellence"]
  agents["<b>Reasoning Agents</b><br/><br/>Requirement Analysis · Gap Detection · Evidence Collection<br/>Compliance · Risk · Proposal Planning"]

  brain --> agents
  agents --> review["Human Review"]
  review --> submit["Final Submission"]

Notice something: the AI never "writes a proposal."

It reasons. It analyses requirements, detects gaps between what is asked and what the organisation can prove, collects evidence, checks compliance, assesses risk, and plans a response.

Writing is simply the last step. That distinction matters.

Trade-offs

Local-first

Gains: privacy, control, compliance. Costs: harder deployment, infrastructure complexity.

The costs are operational and can be engineered down. The gains are structural and compound over time.

Explainability over autonomy

Instead of "trust me," every recommendation explains why, where it came from, and which evidence supports it.

This slows the system down. That is acceptable. A slower answer with evidence beats a fast answer that must be re-verified by hand.

Respect organisational structure

The system deliberately avoids replacing departments. It coordinates them. That makes adoption much easier. Nobody adopts a system designed to make them redundant.

The ugliest compromise

The system deliberately sacrifices autonomy to earn organisational trust. It could do more on its own. It doesn't, because a system that occasionally oversteps loses the trust that makes the rest of it useful. That trade-off is worth documenting precisely because it will be tempting to reverse later.

What changed my mind

When I started thinking about this system, I believed the difficult problem would be analysing procurement documents.

It wasn't.

The difficult problem was understanding the organisation itself.

Large language models already understand language remarkably well. They know very little about:

how this specific company works
who the experts are
which standards matter
what has already been built
why previous decisions were made

I realised I wasn't designing a proposal assistant. I was designing an enterprise memory.

That shifted the architecture completely. Retrieval became only one capability among many. The real challenge became preserving organisational judgement.

Craft excellence

Many AI systems carry a hidden assumption: that knowledge can simply be averaged.

Real organisations do not work that way.

Some engineers consistently design better systems. Some security specialists consistently identify risks others miss. Some proposal managers know exactly how to position the organisation. Their judgement is an organisational asset.

The Company Brain should preserve that expertise, not dilute it into an average. The objective is not merely to answer questions. It is to distribute excellence throughout the organisation: to make the standards of the best people discoverable and reusable by everyone else.

Future evolution

The interesting future is not better models. It is a better organisation.

Today the system helps the organisation understand itself. In the future it should help the organisation improve itself, by identifying:

missing capabilities
recurring proposal weaknesses
knowledge gaps
organisational bottlenecks
departments that rarely collaborate
expertise concentrated in a single individual

Eventually the Company Brain becomes less like a search engine and more like an organisational intelligence system. It doesn't merely answer questions. It helps the organisation learn.

Engineering principles

✓ Local-first where knowledge is sensitive
✓ Architecture before models
✓ Explainability over autonomy
✓ Human accountability
✓ Preserve craft excellence
✓ Model orchestration over model dependence

Status: Living document Last updated: 2026-07-28

This article reflects my current understanding. As I build more systems I expect parts of it to evolve.