Proof · 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, and writes every step back to the ticket.

Nobody logs into NAICOM to start work. They log in to see what happened.

Why this matters

The approval gate is a Jira transition.

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. The authorisation record lives where authorisation records already live, and the artifact — the pull request — is linked to the ticket that asked for it.

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.

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.

NAICOM configuration view: a table of operator roles, each with its model, permission mode, tool count and the JQL query that selects its work — pm on status Ready for PM, code on status Coding, qa on status QA. — The gate, in configuration. Each operator role is bound to a JQL query against the customer's own board — the pm role picks up work at status “Ready for PM”, the code role at “Coding”. Change the workflow and you have changed who may dispatch what. Captured from the demo tenant's configuration view.

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.

NAICOM ticket view for ATLAS-418. A Jira panel showing key, status Done and summary; a rollup strip reading total cost $3.58, 7 dispatches, 10 attempts, 5 roles; and an 18-entry provenance timeline listing dispatches, sessions, prompt files, commits, the pull request and the final Jira status change. — The ticket view for one feature in the demo tenant, captured whole at 1440 pixels wide. Numbered markers are ours; the screen underneath is unmodified.

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, not a log the AI wrote about itself.

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.

Rollup strip from the NAICOM ticket view: total cost $3.58, dispatches 7, attempts 10, roles 5, time-to-merge shown as a dash, status 6 succeeded and 1 failed. — The rollup strip at the head of the same ticket. Time-to-merge reads “—” because of a known defect in the dashboard's renderer, filed and tracked separately; the field is shown as captured rather than cropped out.

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 prove it is a working system rather than a demonstration of one.

NAICOM dispatch log: rows showing status, verdict, role, issue and summary, start time, duration, attempt number and exit code — including pending, running, approved, cancelled and succeeded dispatches across the pm, code and qa roles. — The dispatch log. Every operator run against every ticket — role, verdict, attempt number, duration, exit code, and the pull request where one exists. Failures and cancellations sit in the same list as successes; there is no separate happy path. The instance behind this capture holds 433 dispatches over 90 days.

NAICOM usage view for the last 30 days: total cost $100.48, 90.18 million tokens, 211 dispatches with usage data, a throughput chart by day, and breakdown tables of cost and tokens by role and by repository. — Cost and token attribution for the last 30 days, broken out by operator role and by repository. This is the same claim as the per-ticket rollup at portfolio scale: what AI-assisted delivery costs per repo, per month, without anyone assembling a spreadsheet.

NAICOM configuration view: daemon version, hostname, platform, listen address and paths; the Jira connection showing cloud URL and email, with the token displayed as [redacted]. — The configuration view, redacting its own secrets. Connection details are shown so an operator can verify what the daemon is talking to; the tokens are never rendered. A small thing, but it is the kind of thing that is true or it is not.

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.

Ask for a live walkthrough How NAICOM works