NARC — Designing trust
into AI-assisted detection.
NARC could already read a threat report and map it to MITRE ATT&CK. It just couldn’t do it for anyone unwilling to write and maintain their own software. My job was the other half: making a model’s output safe enough to let it write to a customer’s knowledge base.
NARC existed before I did anything.
It worked — an API that extracted procedure sightings from threat reports and mapped them to ATT&CK techniques.
But it was API-only. Customers who wanted their threat reports reflected in their coverage data had to build and maintain integration code themselves. The team’s own assessment: the adoption barrier was too large.
The underlying job was tedious and manual. Analysts read threat reports and hand-mapped them to ATT&CK, which is slow, inconsistent, and exactly the kind of work a model should be good at.
So the product problem wasn’t extraction quality. It was delivery — and delivery meant letting a model write into the system of record that customers make security decisions from.
That’s a different problem. An API that returns JSON is a suggestion. A feature that updates a knowledge base is an action.
Before designing a screen, the boundaries had to be settled.
Most of these were product and engineering decisions I designed within rather than decisions I made — but they shaped every subsequent interface choice.
What the model received, and what never left the platform.
NARC never received tenant data. Only the API key and the specific report the user chose to submit. Matching against a customer’s existing objects happened inside the platform, not in the model service.
Submitted reports were not stored. A threat report can contain live incident detail. The team chose not to retain it without a demonstrated need — which meant no submission history, no replay, and no analytics on what customers were submitting.
Existing descriptions were never rewritten. NARC could append to list-like attributes — countries, sectors — when the value was new. Narrative descriptions written by a customer’s analysts were left alone.
Saves were atomic. All updates applied or none did. Partial application would have left a knowledge base in a state nobody could reason about.
Each of these removed a capability. Together they defined the design problem: within these walls, how do you make a model’s output legible enough that an analyst can decide what to accept?
Early in the integration design, I asked whether objects and relationships created by NARC should be identifiable as NARC-derived.
The answer was no. The product rationale: implementation complexity, plus a concern that some customers might view AI provenance negatively.
I understood the argument. I didn’t think it survived contact with the actual workflow — if an analyst can’t tell which parts of their knowledge base came from a model, they can’t audit it, and they can’t decide how much to trust it.
By GA, the decision had reversed. The release introduced a “last modified by NARC” timestamp and a dedicated table of NARC-processed objects.
What changed wasn’t the trust argument. It was that the business needed the same thing for a different reason: to show customers what NARC had actually done for them, in order to justify renewal.
I’d have preferred to win it on the user-trust argument. But the outcome is the point — and the reason to tell this story rather than present provenance as a clean decision is that knowing why it eventually landed is more useful than pretending I was simply right the first time.
Pre-GA testing surfaced the sharpest interface problem in the project.
The results table was trying to tell the user two different things in one column: where did this object come from, and what is NARC about to do to it. Those are separate questions, and collapsing them meant that when several objects shared a name, users couldn’t tell whether NARC would create, update, or leave something alone.
Working with the product lead and an engineer, we split them: Matched Object Source became its own column, distinct from Action.
Related fixes followed. The literal placeholder “<object to be created>” became a plain “New” tag. The action during processing changed from “Cancel” to “Abandon,” because cancel implied the system would undo something it couldn’t.
Search inside the results table didn’t work reliably. The obvious move was to fix it.
The deeper problem was worse than a bug: filtering could silently uncheck results the user had already selected and could no longer see. A user could search, narrow, save — and apply a different set of changes than the one they thought they’d approved.
The team removed search entirely and moved it to the backlog.
A results table without search is a worse feature. A results table that silently changes what you’re about to save is a worse product. That distinction is most of what this project taught me.
Four things this project made concrete.
A model that writes to a system of record is a different product than one that returns answers. Every design decision here descends from that. Human review, explicit action labeling, atomic save, no silent description rewrites — those aren’t AI features, they’re what it takes to let a probabilistic system touch data people depend on.
Provenance is not a nice-to-have. I argued for it, lost on complexity and customer-perception grounds, and watched the business arrive at the same requirement from the revenue side eighteen months later. The lesson isn’t that I was right. It’s that AI provenance has more than one constituency, and I’d argued it from only one of them.
Removing a broken feature can be the safer design. Search that silently changes what you’re saving is worse than no search. In a workflow where the output modifies a customer’s knowledge base, “incomplete” beats “quietly wrong.”
Names are architecture. “NARC AI Report Analyzer” would have been obsolete within a year. Choosing the name that didn’t constrain future input types cost nothing at the time and saved a rename later.
An early proposal called this “NARC AI Report Analyzer.” I pushed for the shorter name because the longer one locked the product to a single input type. Nine months later it accepted PDFs, and a year later it was generating reports. Names are architecture.