NAICOM
GENERALLY AVAILABLEAn AI operations control plane built for regulated environments.
NAICOM turns AI-assisted software development into an auditable, issue-linked process. Every session traces from a ticket and a prompt file through to the merge a named person approved.
NAICOM —What it is built to do
Sustains 100+ agent dispatches a day on a single host
Measured, on one workstation with one operator and no tuning — peak observed day, 113 dispatches. Dispatch is a worker queue, so it is designed to scale by adding workers.
Closed beta · running in production at Novaprospect
Request beta access →The problem
AI coding assistants leave no structured audit trail.
Enterprise AI coding tools produce code at the pace of the developer's typing. They do not produce a durable record of which instruction produced which change, under whose authority.
Inside a FedRAMP boundary or a DoD IL environment, controls derived from NIST 800-53 and the NIST AI RMF require that record. Most teams have no way to produce it.
NAICOM closes that gap without slowing developers down.
Corrections
A mistake gets a class, and the class carries the check that catches it.
An operator that reads a stale branch, or reports work delivered that never landed, produces a re-run billed at the same rate as the work. NAICOM records that mistake against a fixed class the moment it is caught, and holds what was claimed beside what was actually true.
The classes recorded most often against a role are composed into that role's instructions before its next run, each with the command that would have falsified the claim. The record is not a log somebody reads later; it is an input to the next dispatch.
What was claimed, beside what was true
An entry is a pair. observed is what the operator claimed, decided or did, in its own words. correction is what turned out to be true. Keeping both is what makes the record
reviewable: a class on its own says a mistake happened, and the pair says
what would have caught it.
- — Dispatch id, role and issue key are read from the running dispatch, so an entry is attributable without anyone typing them.
- — An entry can be moved between classes afterwards. The record keeps what it was before, who moved it and when.
Recurrence is counted
A new entry can be linked to the older one it repeats with --repeat-of.
The pair then counts as one failure that came back, not as two unrelated
entries — which is the difference between a class that looks busy and a
class that is not being fixed.
The count includes the first occurrence, so a chain marked ×2 is one failure that has happened twice.
The classification
Fixed in the dispatcher's source rather than editable at record time, so a class means the same thing in this month's counts as it did last quarter. Each one names the check it implies.
- stale-state
- Read the live source — the server, the default branch, the deployed artifact — not a rendered summary, a local ref, or your own last action.
- unverified-claim
- Before stating it, name the single command that would disprove it, and run that command.
- presence-not-behaviour
- A match, a live process, or a symbol in source proves presence only. A search returning nothing is a claim, not a result.
- guessed-cause
- Ask what your theory fails to explain before you name a cause. Say “unknown” rather than supplying a mechanism that fits.
- false-completion
- A pull request is its diff, not its description. Read the changed files, and ask git whether the default branch contains the commit.
- inference-as-instruction
- Quote the source, or mark it as your own inference. Never hand it back as what was asked for.
- instruction-ignored
- Name the instruction that governs the action before taking it. A rule you had to be reminded of is a rule you already broke once.
- unrequested-scope
- Answer the question that was asked and stop. No unrequested offers, no adjacent threads.
- wrong-mechanism
- Find the mechanism the thing belongs to before improvising one. Use the deploy path a file is deployed by, and dispatch work rather than hand-running it.
- duplicate-work
- Search the board and the open branches before you create anything. Two tickets touching the same files conflict by construction.
- unclassified
- Assign a class so this entry can be counted.
Counts move daily, so here are the commands rather than the numbers
$ novaicom corrections classes
$ novaicom corrections record --class wrong-mechanism \
--observed "..." --correction "..." --repeat-of 198
$ novaicom corrections list --issue ORBIT-129
$ novaicom corrections stats --by week
$ novaicom corrections reclassify 204 --class stale-state
$ novaicom corrections brief --role codeThe last one prints the block a dispatched operator of that role receives — the classes recorded most often against it, and the check each one implies.
How it works
Four pillars of AI traceability.
Each pillar is a concrete artifact the platform produces and retains.
Issue-first traceability
Every AI session opens against a Jira issue. Business requirement → issue → session → prompt file → commit → deployed artifact. No untracked AI work exists in the repository.
Prompt files as audit artifacts
Each task is defined in a versioned prompt file committed to the repo alongside the code it produced. A permanent, diff-able record of what instruction produced what change.
Structured session logging
Sessions are tracked with a durable session ID, role, interface, issue reference and status. The full transcript is retained as a queryable artifact.
Role-scoped dispatch
Operator roles (Research, Arch, Code, QA, DevOps) are spawned as scoped subprocesses with explicit cwd, permissions, and issue context. Separation of duties is enforced at dispatch.
Capability
What it is built to do, and what we have measured.
Each claim below is labelled with its basis. Measured means we ran it and counted. Designed means it is what the architecture supports and we have not yet run it at that size. Ask us where any of these came from and you will get the arithmetic.
100+ dispatches a day on a single host
Peak observed day: 113 agent dispatches completed in 24 hours by one operator on one untuned workstation. The two adjacent days ran 86 and 59.
Scales by adding workers
Dispatch is a queue with role-scoped workers. Throughput is intended to rise as workers are added, which makes the single-host figure a floor.
Thousands of tracked issues
The provenance store is built to hold work across thousands of issues and retain it for the life of the authorization. An audit question about last quarter is the normal case.
8 concurrent projects, routed at once
Eight separate tracker projects routed to their own repositories concurrently, each with its own workflow states and its own operator roles, from one control plane.
Agent tracking across machines
Sessions are bound to a ticket and a durable session ID rather than to a terminal, so work that moves between workstations stays one continuous, attributable record.
Every attempt recorded, including the failures
No-ops, cancellations and failed attempts are written to the same ordered list as successes. There is no separate happy path, which is the property that makes the trail evidence.
How work starts
A workflow transition opens an audited session.
There is no console to log into to begin work. You write the spec into the issue, set its component, and move it to the approval state in your own Jira workflow. That transition is the authorisation — access-controlled, timestamped and attributable inside a system your auditors already accept.
- —Role and issue key are resolved from the workflow status; work with neither is not dispatched.
- —A session ID is allocated before the operator process starts, and the session is recorded against the issue.
- —Every attempt is recorded, including the ones that fail, no-op or get cancelled.
Write the ticket
Spec and acceptance criteria go in the issue description. Set the component so the work can be routed. This is the only place a human types the requirement.
Move it to the approval state
A transition in your existing workflow — access-controlled, timestamped, attributable. That transition is the authorisation. Nothing is dispatched without it.
Read the ticket again
An operator picks the work up, does it, opens a pull request on your forge, and writes every step back to the issue. A named person merges. Nobody logged into a second console.
See it running · real captures
A ticket goes in. A pull request comes out.
The input is a Jira ticket. Nothing else. You file it with a spec, set its component, and move it to the approval state. An AI operator reads it, does the work, opens a pull request on your forge, and writes every step back to the ticket.
Nobody logs into NAICOM to start work. They log in to see what happened.
That single design decision is the whole compliance argument. Moving an issue into the approval state is already an access-controlled, timestamped, attributable event inside a system your auditors accept, with the RBAC and the history they already trust. So nobody is asked to take an AI's word for what it did, or to trust a log the AI wrote about itself. It is a stronger claim than "AI-powered", and unlike most of what is written about AI governance, it is checkable. What follows is the checking.
One unit of work, end to end
The whole trail on one screen.
NAICOM's ticket view merges the prompt files, the dispatches across every role, the sessions, the commits, the pull request and the Jira metadata into one ordered timeline. This is a single ticket — a rate-limiting change on a public API — from its approval to its close. Eighteen entries, nothing assembled by hand.
What the feature cost
Every dispatch against this ticket, priced and totalled. $3.58 for one feature — seven dispatches, ten attempts, five roles.
The approval that authorised the work
The first entry is a human moving the ticket into the approval state. Nothing ran before it. The transition is a timestamped, attributable event in Jira.
The instruction, versioned
The prompt file the operator worked from, committed to the repository beside the code it produced. It diffs like any other file.
The artifact, linked back
The pull request, and under it the ticket returning to Done. One unit of work, closed where it opened.
The number
What did this feature cost?
Not what the platform costs per month. Not tokens. What this feature cost, in dollars, against a unit of work your finance team already recognises — sitting on the same screen as the audit trail for that work.
NAICOM rolls cost up per ticket because it prices every dispatch as it runs. The rollup is the sum of the work the timeline underneath it records.
The figure beside is from the demo tenant. On our own board, a real masthead change to one of our production sites — specified in a ticket, built by AI operators, reviewed and merged — rolled up to $9.17 across two dispatches. That is the unit we are talking about.
In motion
From the board into the trail.
Fifteen seconds, unedited: the dispatch board with work in flight — pending, running, succeeded, failed — and then one of those tickets opened, scrolled from the approval that started it down to the pull request and the status change that closed it.
A screen recording of the demo instance. No cuts, no speed-up, no overlay.
The rest of the instance
It runs at volume, and it prices itself.
One traced ticket proves the mechanism. These are captures of the same system running at volume.
About these captures
Real software, fictional customer.
Every image and the recording on this page are screenshots of NAICOM running. Nothing is a mockup, a rendering, or a diagram of a system. Nothing is composited, redrawn, or captioned as something other than what it shows.
They are taken from a demo instance carrying a fictional customer — invented projects, repositories, tickets and modelled spend — against its own database. We photograph that rather than our production dashboard because our production dashboard is full of our customers' project keys and our own infrastructure. The product in the captures is the shipping product, unmodified; only the data behind it is invented.
That instance is deliberately given no route to a dispatcher, which is why its header reports the daemon as unreachable and the board notes it is reading from its mirror. Both are true statements about the instance we photographed, and we would rather show them than crop them.
Integrations
Two systems of record. One continuous chain of custody.
NAICOM treats Jira as the source of intent and Git as the source of truth. Every AI session binds the two together.
Jira integration
Every session opens against a specific issue. The session is cross-linked into the Jira ticket as a remote link, with status transitions and work logs written back automatically.
- — Issue key required to open a session; sessions without one are rejected at dispatch.
- — Session status mirrors into the Jira workflow:
coding,reviewing,awaiting-feedback. - — Prompt files attach as remote links on the issue at session close.
- — Supports Jira Cloud (REST API v3) and Data Center.
Git integration
Work happens on a branch named for the issue, on the forge that repository already lives on. The pull request is opened there and reported back to the ticket, so the artifact and the requirement that asked for it stay linked without anyone maintaining the link.
- — Opens a pull request on your own forge — GitHub, GitLab, Bitbucket, or Gitea.
- — Branch-per-issue naming, and the pull request is matched back to the issue by branch ownership.
- — A named person merges. The merge is what closes the work.
- — Session logs and prompt files are committed to the repository, so they diff and review like any other file.
Your forge, your workflow
Nothing about the workflow you already run changes. Tickets stay in Jira. Code stays where it already lives. NAICOM reads the ticket, works in a branch on your forge, opens the pull request there, and reports back to the ticket. Nobody moves a repository and nobody logs into a second console.
Forge identity is resolved per repository. An estate with some repositories on GitHub and others on a self-hosted GitLab is a normal customer — each repository declares its own forge and NAICOM routes to it.
Supported forges
- GitHub
- GitLab
- Bitbucket
- Gitea
Cloud or self-hosted. Branch, pull request, and merge all happen on the instance you already operate.
Prompt file
Where a task needs an instruction longer than the ticket itself, that instruction is written to a Markdown prompt file, named for the issue key and committed to the repository beside the code it produced. It is reviewed in a pull request like anything else, and the diff between two versions of it is a record of how the instruction changed.
- —Committed to the repository and reviewable in a diff.
- —Reviewed before the work it describes is dispatched.
- —Diffs across prompt versions are first-class audit evidence.
Compliance alignment
Evidence auditors can actually use.
"Aligned to" is not a control. Each framework below is matched to the specific record NAICOM produces against it, and to what an assessor is handed when they ask.
NIST AI RMF 1.0
Coverage across all four functions. GOVERN: role-scoped dispatch and a required human merge separate who instructs from who approves. MAP 4.1: the prompt file is the documented AI input, versioned with the code. MEASURE 2.8: session records make every AI-driven action traceable to its instruction. MANAGE: the ledger is what an incident review reads. The auditor is handed a per-issue export — ticket, prompt file, session log, commit SHA, approver.
ISO/IEC 42001
Evidence for the AI management system where AI touches the SDLC. Clause 6.1.2 risk assessment scoped per dispatch rather than per organization; Clause 8.1 operational control enforced by role separation at spawn time; Annex A.6.2 life-cycle records generated automatically. Your Statement of Applicability cites artifacts.
EU AI Act
Article 12 record-keeping and Article 14 human oversight, produced as a by-product of shipping. Logs are generated automatically over the system life cycle and every change carries a documented human approval — which is what Article 14 asks for and what a policy document alone cannot demonstrate. High-risk and Article 26 deployer obligations apply from 2 August 2026.
NIST 800-53 — AU family
Contributes to AU-2 (Event Logging), AU-3 (Content of Audit Records), AU-6 (Audit Review), and AU-12 (Audit Generation) for AI-assisted development events. The per-issue provenance record also contributes to SA-11, SI-7, CM-3 and CM-5 without a separate collection pass.
FedRAMP ConMon
Provides queryable evidence for continuous monitoring of AI-in-the-SDLC: who changed what, under what instruction, linked to what authorization-boundary component.
Architecture
Deploys inside your boundary.
NAICOM runs as a self-hosted control plane inside the customer's authorization boundary. Session transcripts, prompt files, and audit data never leave the environment. Supported model endpoints include commercial APIs, private-cloud inference services, and air-gapped on-premises models.
The control plane is delivered as Docker containers with IaC templates. A lightweight daemon runs alongside the developer's terminal to enforce session lifecycle and dispatch rules. Audit storage targets Postgres by default, with write-forward to the customer's SIEM or log aggregation platform.
Dispatch is a worker queue, which is what makes the measured single-host figure a starting point: capacity is intended to be added by running more workers inside the same boundary.
Who this is for
Four things that make NAICOM worth your time.
If your situation is close to these, the conversation is still worth having.
Engineers already shipping with AI
Coding assistants are in use on production repositories today. NAICOM records work that is already happening — it is not a reason to start.
An issue tracker you actually use
Jira, or a tracker with an equivalent API. The issue is the root of the trace, so a team that opens tickets after the fact has nothing to link to.
A governance question with a date on it
An ISO/IEC 42001 certification, an AI RMF self-assessment, an EU AI Act Article 12 or 14 obligation from 2 August 2026, or a customer security review that has started asking about AI.
Someone who owns the answer
A named engineering or compliance contact who will be asked "which of these changes was AI-written, on whose authority?" — and who can tell us whether our export is what they needed.
What the conversation covers
A live instance.
- A live walkthrough of NAICOM running against a real deployment — not slides, and not a recorded video.
- An AI session opening against a tracked issue, the instruction landing in the repository as a versioned prompt file, and the pull request carrying the session ID.
- The auditor-facing export: "every AI-driven change to this component last quarter", as a table.
- Your tracker and your forge — GitHub, GitLab, Bitbucket or Gitea, resolved per repository — and what deployment inside your boundary would take.
- What acquiring it would mean: the repository, the deployment it already runs in, and the team that keeps it running.
What we need from you
Thirty minutes and a named contact.
- A named technical contact who can speak for the environment NAICOM would run in.
- A rough shape of that environment — how many repositories, which forge or forges, and which tracker.
- The deadline actually driving this: a certification, an audit, an authorization date, or a customer security review.
- Thirty minutes. A second, deeper session is common; the first one does not need to be long.
FAQ
What people usually ask first.
What does the first conversation involve?
We walk the running system: an AI session opening against a tracked issue, the instruction landing in the repository as a versioned prompt file, the pull request carrying the session ID, and the export that answers "every AI-driven change to this component last quarter" as a table. Then we look at your tracker and your forge — GitHub, GitLab, Bitbucket or Gitea, resolved per repository — and what deployment inside your boundary would take.
Is NAICOM generally available?
Yes. NAICOM is generally available and has been running Novaprospect’s own engineering in production since 27 May 2026, in SaaS, PaaS, and On-Prem deployments.
Can we run it ourselves first?
That is the normal first step, and the command that stands it up is on this page. NAICOM runs inside your own boundary rather than as a hosted service, so what you evaluate is the shipping software against data that never leaves your machine.
How is it available?
As a closed beta. NAICOM runs in production at Novaprospect every day — the company's own engineering record is produced by it — and access goes to organizations that ask for it and say what they would run it against. Request beta access from this page and you get an answer. Nothing about it is published as a rate. Acquisition conversations are open separately; the acquisition page sets out what a buyer inherits.
Does it work with our forge?
GitHub, GitLab, Bitbucket and Gitea are supported, cloud or self-hosted, and forge identity is resolved per repository rather than per organization. An estate with some repositories on GitHub and others on a self-hosted GitLab is a normal customer.
How much can one deployment actually handle?
A single host has been measured sustaining 113 agent dispatches in a day, run by one operator with no tuning. Dispatch is a worker queue, so it is designed to scale by adding workers rather than by moving to a larger machine. We will size it against your repository and ticket volume when we talk.
How quickly do you respond?
Inside a business day, in practice. Every request gets an answer, and a session is scheduled the same week where the timeline warrants it.
It runs Novaprospect's own engineering.
Every merge on this site was dispatched and recorded through NAICOM, and the command that stands it up on your own machine is above. What is not on offer is a subscription to it.
Closed beta · running in production at Novaprospect
Request beta access →