Engineering Beyond the Model
The model is rarely the whole system.
A useful AI product also depends on the quality of its knowledge, the boundaries around its actions, the way people verify its output and the architecture that allows every part to change independently.
This collection documents how I think about those systems. The case studies carry the evidence; this page is the summary.
Working principles
-
Architecture should outlive today's model. Models are components, not foundations. In Procurement Intelligence, model providers are interchangeable by design, because the valuable part of the system is everything around them.
-
Organisational knowledge is more valuable than a clever prompt. While designing Procurement Intelligence I realised I wasn't building a proposal assistant. I was building an enterprise memory. Language models already know what the internet knows; they know very little about how a specific company works (ADR-004).
-
Privacy is an architectural decision, not a checkbox. The Company Brain remains local because a company's accumulated knowledge should never become someone else's training data.
-
Automation should improve judgement without removing accountability. The Enterprise Review Platform deliberately stays advisory: a recommendation system engineers can interrogate is more valuable than a gatekeeper they do not trust (ADR-003).
-
The right model depends on the task, cost, latency and risk. In the review pipeline, a small model classifies changes before an expensive model reasons about them. Choosing models is an architectural concern, not a default (ADR-002).
-
AI should fit into the organisation's workflow, not force the organisation to fit the AI. MACManager coordinates existing enterprise systems instead of replacing them. The review platform publishes into the review workflow engineers already use.
-
AI should preserve and distribute an organisation's best judgement, not average it away. Every organisation has people whose judgement consistently produces better outcomes. That judgement is the real competitive advantage, and the systems I build treat it as an asset to protect.
What changed my mind
I once thought the largest challenge would be choosing the most capable model.
Building real systems taught me otherwise, repeatedly.
On the review platform, more context made reviews worse, not better; the hard problem turned out to be context selection, not retrieval. On Procurement Intelligence, the hard problem was not analysing documents but understanding the organisation itself. On MACManager, with four people and a fixed deadline, ambiguity was more dangerous than technical complexity. And Signalum keeps reminding me that collecting more opinions is not the same as improving judgement.
The pattern is the same every time: the harder problems sit around the model. Context, ownership, evaluation, permissions, trust and long-term maintainability.
Where to start
- Procurement Intelligence: the Company Brain, and why it is not a RAG system.
- Enterprise Review Platform: context selection, and why "best practice" feedback can be harmful.
- MACManager: what a closed enterprise network and a fixed deadline do to architecture.
- Signalum: an honest work-in-progress on collective judgement.
- Architecture Decision Records: the concrete decisions behind the essays.
Related
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.