About

BWAboutWorkResearch LabNewsletterOff DutyKnowledge Lab

I've been working on knowledge systems for 20 years.

I just didn't always call them that.

Engineer by training. Knowledge Architect by practice. Builder at heart.

I started with an Electronics & Telecommunication Engineering degree and spent the next two decades working across telecoms, semiconductors, hardware, software, cloud, AI/ML, and now energy. The technologies changed. The underlying problem kept showing up.

How do you make complex technical knowledge understandable, maintainable, and useful at scale?

For most of my career, the primary consumer of that knowledge was human. That's changing.

From technical documentation to knowledge architecture.

I began my career building technical documentation for telecommunications and software products. Then the systems became more complex. I moved from writing documents to thinking about information architecture, structured content, reuse, APIs, developer journeys, documentation platforms, and the systems that produce knowledge at scale.

The lesson wasn't simply that better documentation works. It was that knowledge architecture affects the behaviour of the entire system around it.

Verified outcomes from that work, with dates and organisations, are on the Work page.

Then the consumer changed.

LLMs and AI agents introduced a new user persona. A machine. And machines are remarkably good at exposing bad knowledge architecture.

Duplicate sourcesMissing contextWeak metadataAmbiguous terminologyStale documentationPoor provenanceInformation without ownership

Humans have spent decades compensating for these problems. Agents don't. They retrieve them, and occasionally turn them into extremely confident answers. That changed how I think about documentation.

The Knowledge Layer

Today I think about documentation as one interface into something larger: the Knowledge Layer. It sits between:

Product · Engineering · Data · Service Delivery · CX
↓
the Knowledge Layer
↓
Humans · Developers · APIs · LLMs · Agents

Information Architecture · Ontology · Taxonomy & Metadata · Governance · Canonical Sources · Technical Documentation · APIs · Retrieval · Evaluation · Knowledge Graphs · Agent Interfaces

The objective isn't more content. It's a system in which the right knowledge can be found, understood, trusted, and acted upon.

Now: Energy.

Today I lead Knowledge Architecture and Docs Engineering across two Energy Flexibility products at Kraken. It's an unusually interesting place to work on this problem. Energy systems are becoming increasingly distributed, software-defined, and automated. VPPs coordinate distributed assets. EMSs optimise energy. DERs participate in flexibility. Markets, grids, devices, APIs, data, and increasingly intelligent systems all need to interact.

Underneath that sits an enormous knowledge problem: the kind I now spend most of my time on. More on the current role is on the Work page.

What I'm building next.

I'm particularly interested in the intersection of Knowledge Architecture × AI & Agents × Energy Systems. What's actually built or being tested (knowledge graphs, ontologies, evaluations) lives publicly in the Knowledge Lab, not here.

Enter the Lab →

A thesis I'm testing.

For years, organisations treated documentation as an output. Then we started treating docs as a product. I think the next transition is larger: knowledge becomes infrastructure.

Documentation becomes one interface.APIs become another.Search becomes another.RAG becomes another.Agents become another.

The strategic problem becomes designing the underlying knowledge so every one of those interfaces can reliably use it. That's the layer I'm interested in building.

Binoy Watts
Knowledge Architecture · AI Knowledge Systems · Docs Engineering · Energy
← back home