The AI Analyst Operating System: Eleven Parts, One Working Week

The stack is one loop, not eleven tools: ground it, read it, verify it, write it, prove it. Build it over 90 days in order, ending with write access rather than starting there. Measure four delivery numbers. And be clear about what moved: not the value of prompting, but the value of verification, judgment, and knowing what your system actually does.

Eleven parts is a lot of parts. This is part twelve of The AI Analyst, and its job is to make the whole thing small enough to hold in your head, small enough to build without a project, and specific enough to describe in an interview.

The whole series is one loop

Strip the tooling and every part of this series is one of five verbs applied to a different artifact.

Verb	What it means	Where it appears
Ground	Give the model your material before it answers	Context pack, the vault, the schema
Read	Use it to read what you cannot read at scale	Codebase, backlog, transcripts, notes
Verify	Check every claim against the system	Every part. This is the whole discipline
Write	Let it produce only what is mechanical and reversible	Jira and Confluence, collections, queries
Prove	Thread identifiers so coverage is demonstrable	Test plan, traceability, CI gate

Learn the loop and you can apply it to something this series never covered, which is the point, because the tools will change twice before this article is two years old and the loop will not.

The 90-day build order

Do not do it all at once. Each step depends on the one before, and the order is not arbitrary: the controls have to exist before the capability.

Days 1 to 14: ground and protect. Build the context pack. Glossary, contracts, data dictionary from the actual schema, numbered business rules, decision log, two worked examples. Load it into project knowledge. Write the ten-line rules of engagement and get your delivery lead to agree to them. That is the foundation and it is genuinely two weeks of part-time work.

Days 15 to 30: the meeting pipeline. Four extractions per workshop, published within the hour. This is the fastest payback in the series and it is entirely low risk, which makes it the right thing to be visibly good at first.

Days 31 to 45: read the system. Clone one repository and answer the one business rule you argue about most. Connect Jira and Confluence read-only and run the contradiction report. Start the vault habit: every workshop, every incident, dated filename, one-line summary.

Days 46 to 70: the delivery artifacts. Build one test plan end to end for one feature, with the traceability matrix and the three gap lists. Turn the API cases into a collection with real assertions and get it running in CI as an advisory check.

Days 71 to 90: reporting, then write access. Automate the weekly pack assembly and write the narrative yourself. Define the three metrics your programme argues about. Only now enable write access to Jira and Confluence, with draft-approve-write, the service account, and the ai-drafted label.

Write access last is the load-bearing part of that order. Teams that start there spend their credibility before they have any, because the first visible output of the whole effort is forty tickets nobody asked for.

What the week actually looks like

Concretely, on a normal delivery week, after the 90 days:

Monday. Sprint starts. Run the readiness check across the next two sprints: which tickets have no testable acceptance criteria. Take the list to refinement instead of a complaint. Before each developer conversation, sharpen the question first.

Tuesday. Design workshop. You are present in it, because the transcript happens without you. Four extractions afterwards, published at 16:40. The contradiction between the cut-off time on the design page and the one in the ticket goes out by email the same afternoon.

Wednesday. The new epic. Read the linked repository to find where the rule actually lives and what the pull request in flight changes. Draft the child stories with assumptions separated, review them, create them assigned.

Thursday. The weekly pack assembles itself at 07:00. You write two paragraphs. Test plan work for next sprint’s feature: risks ranked by you, conditions and cases generated, the matrix showing two requirements with no coverage. That is your Friday agenda.

Friday. The collection for the new endpoint, generated from the contract, assertions reviewed, one test deliberately broken to prove the suite notices. Monthly: what should I have published from my notes, and publish two of them.

Nothing in that week is exotic. What changed is that the artifacts exist, they exist on time, and you spent your attention on the parts that need a person.

Measure four things

Track these before and after, or the whole effort is a matter of opinion and will be cut by the first person who dislikes it.

Metric	Direction	What it tells you
Days from workshop to issued draft specification	Down	Drafting is no longer the bottleneck
Clarification comments per specification	Down	The drafts are actually clearer, not just faster
UAT defects traced to missing or ambiguous requirements	Down	Coverage improved rather than degraded
Test coverage of risks you ranked high	Up	You are testing what matters, not what is easy

The pattern to watch for is the first falling while the second and third rise. That means you are producing documents faster and defects with them, and the cause is always one of two things: grounding is missing, or verification is being skipped because the output reads well. Fluency is not accuracy, and a polished paragraph containing an invented rule passes a review that a clumsy one would fail.

How to lead this on a team

Do not open with a policy. Open with an artifact.

Publish one thing that is obviously better than what the team had, and say nothing about how you made it. The two that convert sceptics fastest, in my experience:

• The contradiction report. Every place the backlog and the wiki disagree, quoted, with keys and dates. Nobody argues with two quotes.
• The readiness list. The eleven tickets in the next two sprints with no testable acceptance criteria. This one makes you popular with testers immediately.

Both are useful before anybody has an opinion about AI, which is the point. Then share the method with one colleague, then the guardrails, then propose the shared context pack. Policy-first adoption produces a policy. Artifact-first adoption produces a team that wants the policy.

Two failure modes to watch for while you do it. The team that automates the writing and skips the verification, which shows up as review comments rising, and the team that treats the tool as a competition, where people stop asking each other questions because asking the assistant is faster. The second one is subtle and costly: a lot of what makes a delivery team work is the four-minute conversation where someone mentions the workaround from 2019, and nothing in this stack contains that.

What this is worth to your career

Be honest about what changed and what did not.

What got cheap: drafting, enumeration, summarisation, boilerplate, format conversion, first-pass code reading, and finding things in large corpora. All of it was real work. None of it was ever the senior half of the job.

What got more valuable, because it is now the constraint:

• Verification. The ability to confirm what a system actually does, from code, logs, database, and contract. The technical analyst skill matrix is the map of that skill set.
• Judgment. Which risk matters, what to cut when the date moves, whether to release. See the go/no-go call.
• System knowledge. The undocumented behavior, the workaround, the integration that has been fragile since 2019. This is why reading the codebase and keeping a vault compound.
• Accountability. Someone signs. That has never been a tool and is not becoming one.

So the honest answer to “will AI replace analysts” is: it replaces the part of the role that was already being done badly under time pressure, and it raises the value of the part that was always being squeezed out to make room for it. An analyst whose contribution was typing up other people’s conclusions is in trouble. An analyst who can prove what a system does is worth more than they were in 2024, because they can now produce several times the output and still stand behind every line.

On a CV or in an interview, describe outcomes and controls, not tools. Not “experienced with AI tools.” Instead: “Built a grounded AI workflow for a payments programme: context pack, read-only Jira and Confluence integration via MCP, generated test plans with full requirement-to-test traceability, and an API suite gating merges in CI. Cut time from workshop to issued specification from three days to half a day while reducing clarification comments.” The second version says you understand delivery, governance, and evidence. The first says you have an account.

If you want the full library behind the series, the complete set of guides is bundled in The Complete Tech BA Bundle, and if you would rather work through applying it to your own programme, a 1:1 coaching call is the direct route.

The five rules, if you remember nothing else

1. Ground everything. No grounding, no output worth having.
2. Ask for locations and quotes, not explanations. A file and a line is checkable; a narrative is not.
3. Verify every fact against the system. If you cannot point at where it came from, it does not ship.
4. Read-only for longer than feels necessary. Every write is an artifact somebody will find later.
5. Keep the judgment. Risk ranking, scope, priority, sign-off. That is the job, and it always was.

The takeaway

The AI analyst operating system is one loop applied to eleven artifacts: ground, read, verify, write, prove. Build it in 90 days in the order given, ending with write access rather than starting there. Measure four delivery numbers and watch for the pattern where drafts get faster and review comments rise. Lead adoption with an artifact, not a policy.

The value did not move to prompting. It moved to verification, judgment, and knowing what your system actually does, which is where it was always supposed to be and where the time was never available. Now it is.

Start at part one if you have not, and the whole path is mapped on The AI Analyst. If you would rather practise than read, the Labs give you a fictional payments platform with real artifacts and one deliverable per mission, which is exactly the material this workflow is built to chew through.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Business Analysis, Artificial Intelligence, Career, Productivity, Delivery