The MIRR Guide

The definitive guide to MIRR, a governed framework for AI-augmented project management.

Version 1.0 · September 2026 · Created by Juan Romero · the-mirr.com

Purpose of this Guide

MIRR was created by Juan Romero to let project and program managers work from evidence instead of memory, and to let one manager carry more projects without losing depth on any of them.

This Guide defines MIRR. It sets out the four commands, the rules that hold them together, the records they produce, and the limits of what MIRR does. It deliberately says nothing about which products, models or tools to use. Those choices differ at every company, and MIRR is designed to work with whatever a company already runs.

If you follow what is written here, you are using MIRR. If you leave out a part, especially the approval gate, what you are running may be useful, but it is not MIRR.

1. What MIRR is

MIRR is a way of running projects in which an AI framework is connected to the tools a team already uses: the ticket system, the group chats, the email, the calendar, the document folders. It does the administrative half of project management, and it asks a human for permission before it changes anything, anywhere.

MIRR consists of:

• four commands, run in a fixed order: initialize, map, refresh, report;
• one rule that governs everything: nothing reaches a real system without an explicit human yes;
• three guarantees that make its output trustworthy: approval gates, read-back verification, and citation discipline;
• four records that every project keeps: the project context, the source list, the approval log, and the weekly status.

The name spells the commands in a different order than they are run. That is intentional and harmless. The order that matters is the order in section 5.

2. The problem MIRR addresses

A project manager's week carries two costs that create no value on their own.

Administrative overhead is the visible one: ticket hygiene, meeting minutes, status updates, chasing owners for dates.

Reconstruction is the hidden one. Every time a manager switches projects, they rebuild the picture from scratch: where things stand, who owes what, what was decided. The information exists, but it is scattered across systems that do not know about each other.

Together these crowd out the part of the job that needs a human: judgement, relationships and decisions. MIRR treats this as an architecture problem, not a discipline problem, and solves it with structure rather than effort.

3. Principles

MIRR rests on seven principles. Every rule in this Guide follows from one of them.

1. Evidence over memory. What the project knows is built from what the systems recorded, not from what anyone remembers.
2. A human approves every outbound action. The framework proposes. A person decides. There is no autonomous mode.
3. Read it back. A write is not done until it has been read back and matches what was approved.
4. Cite it or cut it. Every factual claim points to its source. A claim that cannot be traced does not ship.
5. One shape for every project. Every project is structured the same way, so that nothing learned on one is lost on another and the portfolio can be compared.
6. Say up front what cannot be done. Before anything runs, the framework checks that the tools can support every step. It never discovers a gap halfway through.
7. The truth stays where it lives. MIRR is not a system of record. It reads from and writes to the tools the organisation already has.

4. Roles

MIRR has three roles.

The operator is the project or program manager who runs the commands. The operator owns every decision and every approval. The operator is accountable for what reaches a real system, because nothing reaches one without their yes.

The framework reads the mapped sources, works out what changed, drafts what needs drafting, proposes actions with their reasoning and sources, executes only what was approved, and reads back every write. It decides nothing and owns no relationship.

The organisation sets the conditions MIRR runs in: which tools exist, how the framework is allowed to reach them, what the security team has signed off, where project knowledge is stored, and what the organisation calls the levels of its work. This is done once, before any operator starts.

5. The four commands

The commands run in this order:

initialize  ->  map  ->  refresh  ->  report
                           ^            |
                           +------------+   (refresh and report repeat for the life of the project)

Initialize and map run once, when a project starts. Refresh and report run for as long as the project lasts. Whenever a project's sources change, the cycle returns to map.

5.1 Initialize

Purpose: give a new project its complete structure before any work begins.

When: once, at the start of a project.

Input: the project's scope document.

What it produces: everything the project needs, in the same shape as every other project. Typically: the project folder, the document repository, the meeting-minutes notebook, the project chat channel, the project in the ticketing system, the first tickets, and the kick-off message to the team. The project also gets its own isolated context, so two projects never bleed into one another.

Gates: every item it would create in a real system is shown in full and approved before it is created.

Done when: every item exists, has been read back, and the project context records where each one lives.

5.2 Map

Purpose: record where this project's information actually lives.

When: once after initialize, and again whenever the project's sources change.

Input: the operator's knowledge of the project, and what the framework can discover.

What it produces: the source list (section 7.2): the ticket board, the chats, the calendar, the mailbox threads, the document folders, and who the people are.

Gates: the operator confirms every source before it is trusted. A wrong source means the wrong people get updated later.

Rule: map only reads. It changes nothing in any system.

Done when: every source on the list has been confirmed by the operator.

5.3 Refresh

Purpose: keep the project current, every day.

When: daily, or at whatever rhythm the project needs.

Input: everything new in the mapped sources since the last refresh.

What it does: visits every mapped source, reads everything new, works out what actually changed, updates the project context, and comes back with a list of proposed actions. For example: update this ticket, send this recap, email the attendees, flag this new risk, close this finished piece of work, or ask whether an apparent change of scope is real.

Gates: each proposal shows its reasoning and where it came from. Then the framework stops and waits. Nothing is sent or changed until the operator approves.

Rules:

• Every new document found in a source is read, not just noted by name.
• The project context is updated before any deliverable is produced from it.
• Every status the framework relies on is checked against the live system, not remembered from last time.

Done when: the project context is current and every proposal has been approved, modified or rejected.

5.4 Report

Purpose: produce the status that leadership actually reads, built from what happened.

When: weekly, or at the organisation's reporting rhythm.

Input: the project context, freshly refreshed.

What it produces: the weekly status (section 7.4): how the project is doing, what got done, what is at risk, what is next, and what needs a decision.

Rules:

• Same shape for every project, every week.
• Every line must pass one test: would a leader act on it or remember it? A line that fails is cut.
• Every claim traces to a source in the working record, even though the published status carries no citations.

Gates: the finished status is shown in full and approved before it is published anywhere.

Done when: the approved status is published and read back.

6. The approval gate

The approval gate is the rule that makes MIRR safe to connect to real systems. It is not a setting. It is how MIRR is built.

A gate is a stop. Before any outbound action, the framework shows the operator exactly what it intends to do, in full: the destination, the exact content, the reason, and the source that justifies it. Then it does nothing until the operator answers.

The operator has three answers: approve, modify, or reject. Modify returns the proposal for another look. Reject means nothing is sent, and that outcome is recorded too.

What must pass a gate: every write, every message, every email, every ticket created or changed, every status change, every field update. Changes of state are gated the same way as messages.

What never needs a gate: reading. Map and the reading half of refresh change nothing, so they run freely.

Grouping is allowed; hiding is not. Related actions may be approved together, but every item in the group is shown in full.

Repetition is the point. A single daily run may stop several times. That is intentional. The repetition is what turns the promise of human control into a fact.

If a gate can be switched off, skipped when someone is busy, or approved without seeing the content, the process is not MIRR.

7. The four records

Every MIRR project keeps four records. They are the project's memory, so the operator never has to be.

7.1 The project context

The living description of the project: what it is, its structure, where everything lives, who is involved, the current state of every piece of work, decisions made, risks, and open questions. It is updated on every refresh, and every fact in it points to its source.

The project context lives in an environment the organisation controls. Not in an uncontrolled external repository, and not on the operator's own computer.

7.2 The source list

The confirmed list of where this project's information lives. For each source: what it is, where it is, why it matters to this project, and when the operator confirmed it. Nothing outside the source list is treated as evidence for the project.

7.3 The approval log

A record of every action the framework proposed, what the operator answered, what was actually executed, and whether the read-back matched. It makes the whole sequence replayable for a compliance review or an incident.

7.4 The weekly status

The published report. Its shape is the same for every project:

• Status: one sentence on how the project is doing, and if it is not on track, what gets it back on track and by when.
• Objective: what the project is and why it exists, in two lines anyone can read.
• Accomplishments: outcomes that matter, not activity.
• Key milestones: what is coming next, with dates.
• Risks and decisions needed: kept visible, and owned.

8. The three guarantees

Approval gates. Every outbound action is shown in full and approved before it happens (section 6).

Read-back verification. After every write, the framework reads the record back and compares it with what was approved. A write that silently failed, or that a permission quietly rejected, is never reported as a success. What was approved is what was written, or the operator is told it was not.

Citation discipline. Every factual claim in every deliverable resolves to a source: a ticket and field, a transcript and timestamp, a document and section, a row and column. A claim that cannot be traced does not ship.

9. Setting MIRR up in an organisation

MIRR is set up in two layers, always in this order.

The company layer, once. Which tools the organisation uses. How the framework is allowed to reach them. What the security team has signed off. Where project knowledge is stored. What the organisation calls the levels of its work. Which AI model runs it, chosen for the organisation's risk posture: cloud under contract, private deployment in-region, or fully self-hosted.

The person layer, for each operator. Who they are, which projects they run, and their working conventions. This is short, because the company layer has already done the heavy work.

Three design rules keep MIRR portable between organisations:

1. Steps name what must happen, never which product does it. A step says "add a comment to the ticket", not the name of a product's feature. Setting MIRR up means pointing each step at whatever the organisation actually runs.
2. Check before running. Before a command runs, the framework confirms the organisation's tools can support every step it needs. A missing essential step means the command does not start, and the reason is given. A missing optional step is marked as skipped. Automation that stops in the middle of a live system is worse than automation that refused to begin.
3. Company settings and personal settings never mix. Keeping them apart is what lets one company setup serve many operators, and lets MIRR move to another organisation at all.

Least privilege by inheritance. The framework reaches only what the operator is already authorised to reach. It inherits access. It never expands it.

10. What MIRR is not

• It does not decide. It prepares decisions. A human makes them.
• It owns no relationship. Meetings, trust, hard conversations and negotiation stay human.
• It never acts unsupervised. There is no autonomous mode to switch on.
• It is not a system of record. The truth stays in the tools the organisation already has.
• It is only as good as its sources. Map a project to the wrong channel and it will faithfully report on the wrong channel. That is why mapping has a human confirmation step.
• It does not remove the need for a good project manager. It removes the reasons a good one runs out of hours.

11. Failure modes, and where each is caught

Three kinds of failure, three catches, each at a different layer.

12. Adopting MIRR: a 90-day pilot

MIRR is adopted by a pilot, not a rollout. One team, a handful of programs, one quarter. No new system of record and no change to the tools already in use.

Weeks 1 and 2, stand up. Complete the company layer. Agree the governance and data-classification posture with the security team before anything runs. Initialize and map the pilot programs. Take a baseline.

Weeks 3 to 8, run and measure. Run the daily refresh and the weekly report on the pilot programs. Measure against the baseline. Tune in flight.

Weeks 9 to 12, decide. Review the evidence and decide: scale, adjust, or stop. A clean decision either way, made on measurements rather than a feeling.

Agree these five measures up front: hours reclaimed per manager, reporting cycle time, reporting consistency, stakeholder-response latency, and security sign-off.

Worst case: one quarter and one team spent. The structure and the learnings are kept either way.

13. Using the name

You may say you use MIRR, teach MIRR, or build on MIRR when you follow this Guide. In particular, the approval gate, read-back verification and citation discipline are not optional. A process without them may borrow ideas from MIRR, but it should not be called MIRR.

When you use, share or adapt this Guide, credit it like this:

MIRR was created by Juan Romero. The MIRR Guide is available at the-mirr.com.

License

This Guide is offered under the Creative Commons Attribution-ShareAlike 4.0 International License (CC BY-SA 4.0). You may copy, share and adapt it for any purpose, as long as you credit Juan Romero as the creator of MIRR, link to the-mirr.com, indicate if changes were made, and share any adapted version under the same license. The full license is at creativecommons.org/licenses/by-sa/4.0.

MIRR and the MIRR logo are the names and marks of the framework and are not licensed by this Guide.

About the creator

Juan Romero is a cybersecurity program manager at a major Silicon Valley company. He built MIRR to run his own portfolio, where it took him from five concurrent programs to sixteen in the same hours, and it runs in production there. The full story is in the article MIRR: How I Went From 5 Projects to 16 Without Adding Headcount, linked from the-mirr.com.

Version history

• 1.0 (September 2026): first public version.