Two versions of the process,one list of the gaps

A gap analysis is two documents and a week of cross-referencing: the vendor's target spec on one screen, how your team actually works on the other. Khint reads the spec file where it sits, searches your own Jira and Confluence for the current behaviour, and turns the difference into a gap register the steering group can act on.

For business analysts and product owners on a migration, a system replacement, or a vendor selection.

The two states live
in two different places

The to-be state arrives as a file: a 60-page vendor spec, a functional design, a signed statement of work. The as-is state is nowhere so tidy. It is spread across old Confluence pages, closed Jira tickets, and the three exceptions only the team lead remembers. Comparing them by hand means keeping both in your head long enough to notice what is missing. Khint reads the file and searches your own indexed tools in the same run, so the comparison happens once instead of paragraph by paragraph.

KhintPalette
Sprint 24
Workflows

The real palette running a saved workflow: the agent steps run first, then the last step writes the result straight into the tools your team reads.

From two sources to a reviewable gap register

Replacing an in-house billing tool with a vendor product, in one afternoon of reading.

  1. Open a session for the migration

    Start a Memorysession called “Billing platform migration” before you open anything else. Every action you run and every write you make is logged to it, and Khint keeps a compact working state alongside: the objective, the open threads, the decisions already taken. That summary rides along on each later run, so by the third document you are not restating the project in every prompt. Sessions live in a local database on your machine and are never synced.

  2. Point an agent at the target spec

    An agentcan take a document as its input instead of a selection. Pin the vendor's spec (PDF, Word, PowerPoint, Excel, OpenDocument, RTF, or plain text) and Khint extracts the text on your machine, with no upload of the file itself. Anything past a few pages is condensed into a digest that is cached against the file's contents, so re-running the agent on an unchanged spec costs nothing extra, and a new version of the file regenerates it by itself.

  3. Let it read your as-is instead of retyping it

    Switch on Knowledgeand your connected Jira, Confluence, Notion, and Linear content is indexed into a local search index on your own machine, never on Khint's servers. Tick “Search Knowledge” on the gap-analysis agent and each run searches that index on the text it was given, then attaches the handful of most relevant excerpts. The old process page and the ticket where the exception was agreed come back into the comparison without you going to find them.

  4. Capture the parts that only exist on a screen

    Some of the target behaviour is never written down: it is a screen in the vendor's demo, a field list in a system nobody can export from. Use Capture to drag a region and get the text on your clipboard, or Capture and ask to hold a short conversation about the screenshot and save the useful part to the session. The captured text joins the same register as everything else.

  5. Publish the register and ask for the decisions

    Save the two agents plus a write step as one workflow and the whole pass runs from a single shortcut: read the spec, draft the register, create the Confluence page. The last step can instead fan out to two, three, or four destinations at once, so the page is created and the decisions it needs are posted to the squad channel in the same run. Each write is logged back to the session, so the trail of what was published stays with the project.

One shortcut, spec to published register

Up to five steps in series, starting from the document you pinned.

AgentRead the target specAgentDraft the gap registerConfluenceCreate page

A workflow can start from a document, so the vendor spec is the workflow's input rather than something you paste in. Each step's result becomes the next step's input: the first agent returns the target behaviours, the second turns them into a register with a row per gap, and the write step turns that into a page whose URL comes back as the result. Swap the final step for a fan-out and the same run also posts the open decisions to Slack and opens the analysis ticket in Jira.

What it will not do for you

A gap register is a document other people commit budget against, so it is worth knowing exactly where the machine stops.

It compares what you point it at

The agent sees the file you pinned plus the excerpts the local index returned for that run, and nothing else from your screen or your drive. A rule that lives only in someone's head is not a gap it can find. The register is as complete as the sources you give it, which is why the capture step exists.

A scanned PDF is refused, not guessed

Khint reads a PDF's text layer. A spec that is really a photograph of a printed page comes back saying there is no text to read, rather than returning an empty analysis you would take for a clean bill of health. Screenshot the page and run it through Capture instead, which is the path built for pictures of text.

The local index is a copy on a schedule

Your Jira, Confluence, Notion, and Linear content is synced into the local index shortly after launch and then every half hour, not queried live. A page someone edited two minutes ago may not be in it yet. Sync now forces a pass, and switching a source off deletes its local copy straight away.

One write per run, on purpose

A write step creates one page, one ticket, or one post, and a fan-out is two to four destinations rather than a batch of twenty. Writes into other people's tools cannot be taken back, so publishing stays a deliberate act: you pick the space or the channel before the run, and cancelling costs nothing.

Where the client's spec actually goes

On a migration you are usually reading someone else's confidential document, which makes the plumbing worth stating plainly. The file is read on your machine and never uploaded; what reaches the model is the text of the run, and only for the run you asked for. The local index of your Jira and Confluence stays on your machine. Memory sessions and their entries are stored locally and never synced. If a source document carries personal data, an agent can be set to replace emails, phone numbers, and account identifiers with placeholders before the text leaves the device, and on the Lifetime plan you can point Khint at your own API key instead. See how Memory stores a session.

Common questions

What is an as-is to-be gap analysis?

It is the comparison a business analyst runs when a process or a system is about to be replaced: the as-is state is how the work happens today, the to-be state is what the target system or the new process will do, and the gap is everything in between that somebody has to decide, build, or drop. The deliverable is usually a register with a row per gap: the current behaviour, the target behaviour, the impact, and the decision it needs. Khint helps with the reading and the drafting: it takes the target spec as a document, pulls the current behaviour out of your own indexed Jira and Confluence, and returns a register you edit rather than a blank page you fill.

Does Khint read the vendor's spec file itself?

Yes. An agent's input source can be a document instead of the text you selected, so you pin the file once and run the agent on it. PDF, Word, PowerPoint, Excel, OpenDocument, EPUB, RTF, and plain text files are all read locally on your machine. Long documents are condensed into a digest that is cached against the file's contents, so running the agent again on an unchanged spec does not pay to read it twice, and saving a new version of the file regenerates the digest by itself. The source file is only ever read, never written to.

How would it know how our current process works?

From your own tools, if you switch Knowledge on. Khint syncs the Jira issues, Confluence pages, Notion pages, and Linear issues you have connected into a search index held in a local database on your machine, never on Khint's servers. Tick Search Knowledge on an agent and every run of it searches that index using the text it was given, then attaches the most relevant excerpts to the prompt. That is what lets a gap-analysis run cite the process page written eighteen months ago without you remembering it exists.

Can the gaps be filed as tickets automatically?

The register can be published in one run, and the gaps can be opened as work in the same workflow: a write step creates the Confluence page, and a fan-out can add a Jira issue and a Slack post to the same keystroke. What Khint will not do is spray twenty tickets from one run. Each write step is one deliberate write, with the space, the board, or the channel picked before the model call, so a cancelled run never costs anything and a published page is always one you chose to publish.

Is this different from a change request impact analysis?

They answer different questions. An impact analysis starts from one requested change and asks what it touches in a system you already know. A gap analysis starts from two whole states, today and the target, and asks what is missing between them. The register it produces is normally the input to a migration backlog rather than a verdict on a single ticket. Khint supports both, but the gap analysis is the one that needs two sources read at once, which is why it leans on documents and the local index rather than on a selection.

Run your next gap analysis in an afternoon

Free with 300 credits a month, about 10 AI actions a day. No credit card. Save the workflow once and every later version of the spec goes through the same pass.