This was a piece of federal Canadian infrastructure that did something unusual in 2004: it let a deputy minister or minister walk to a microphone with field information from Natural Resources Canada staff across the country in their briefing notes, gathered as close to real time as the security and approval workflow would allow. The Knowledge Asset Inventory was the part of the system I built.
The problem
When a federal minister steps in front of a press microphone, the question they’re least prepared for is the one a journalist heard about an hour earlier from a community in northern Ontario or coastal British Columbia. The information exists — NRCan staff are on the ground in every province and territory — but the channel to move that information from a field office in Whitehorse to a briefing folder on Sussex Drive, with verification and approval at every step, used to take days.
The Brief In Notes system this was part of — the tool that produced ministerial briefing material ahead of media events — was meant to close that gap. Field personnel and NRCan employees input information that worked its way up an approval chain, verified by mid-level civil servants and approved by senior civil servants, before ministers and deputy ministers received the briefed version. The goal was to give a minister near-real-time information before stepping in front of a microphone, instead of last week’s snapshot.
A knowledge-asset inventory inside a briefing-notes workflow
An inventory of knowledge assets for a federal department is a different shape of build than a transactional workflow. The records were not requests moving through approval gates; they were photographs, illustrations, technical papers, and reports that NRCan staff across the country needed to retrieve quickly when a briefing was being assembled. That changed every schema decision. Taxonomy depth mattered more than throughput. Cross-asset relationships — this photograph documents the same forest fire as that technical paper — were load-bearing in a way they would not have been on a request-and-approval system. Read-heavy access patterns dominated; writes were the exception.
The build used the same FileMaker-PHP bridge pattern documented in the NRCan Conference Plan engagement, tuned here for the inventory’s read-heavy access profile. The stack was unusual for a 2004 federal-government build: FileMaker Pro as the primary database (because that is where NRCan’s institutional knowledge already lived), PHP as the front-end, Microsoft’s Internet Information Services (IIS) as the web server, all running inside the federal government’s security envelope. The bridge respected the security requirements of a federal environment, where every connection and every data transfer had to clear a bar higher than commercial work asks for.
The Knowledge Asset Inventory was the searchable layer on top of that bridge. NRCan staff across the country could store and retrieve the raw material that informed everything from a deputy minister’s briefing to a public-affairs response to a press query.
What it taught me
The hardest part of a system serving senior decision-makers is almost never the front-end. It’s the chain of trust between the person who knows the field reality and the person who has to defend the government’s position on it in public. That chain is workflow, approval gates, and verification — and getting it wrong has consequences that show up on the evening news.
FileMaker Pro was the right answer for NRCan’s institutional knowledge in 2004 — it was already there and the staff already knew it. The same problem in 2026 would almost certainly start with WordPress, a custom workflow plugin, and a much shorter list of bridges to build.
