“The soffit detail at the entry doesn’t work — someone should ask the engineer.”
No number. No owner. No date. Nothing is waiting on it.
When does a note become something you owe?
Registering it is not filing it. It is accepting it.
Identity
A number the practice and the client can both refer to, which a note in a document does not have.
Owner
Somebody answerable for it, rather than whoever happens to remember.
Due state
A date it is measured against — carried by an RFI, not by a decision that is simply recorded.
Consequence
A commercial effect elsewhere. A variation moves the fee position; an issue does not.
History
What was asked, what was answered, and when it changed, kept against the item itself.
Not every record type takes every one of these. That is the difference between distinct record types and a single task list with a category field.
Each type owes something different.
Registers
A note owes nothing. A register entry owes somebody something
- ItemOwner—Due—reaches nothing
- ItemOwner—Due—reaches nothing
- ItemOwner—Due—reaches nothing
- ItemOwner—Due—reaches nothing
- ItemOwner—Due—reaches nothing
Five notes. Nobody owes anything, nothing is due, and none of them reaches any other part of the practice.
Registers belong to a Project Pod and roll up practice-wide. Ownership is a state Mudo holds on the record — no project, number, date or person is real.
In short
AvailableAvailable now to practices on a qualifying plan.- What it is
- The delivery registers, covering RFIs, issues, decisions, actions, variations, risks and deliverables, held per project and viewable across every project at once.
- Who it is for
- Project architects running contract administration who currently keep five spreadsheets and a numbering convention.
- What is different
- These are distinct record types with their own behaviour, not a single task list with a category field. A variation carries a commercial consequence; an RFI carries a response obligation and a date.
- Availability
- Available on every plan, including the free Starter tier.
- How it connects
- Registers belong to a Project Pod and roll up into practice-wide registers. Variations affect the fee position; deliverables take their dates from the programme.
Part of Deliver.
Verified against the Mudo application on .
Why these are not tasks
A general work tool would model all of this as tasks with labels. It is a reasonable simplification and it fails for a specific reason: these record types do not behave alike.
An RFI has a respondent outside the practice and a date by which an answer is needed. A variation changes what the practice is owed. A decision needs to be findable in two years when somebody asks why. A deliverable has an issue date the programme depends on.
Flattening them into one type means the practice re-implements the differences in conventions, spreadsheets and habits, which works exactly as well as the person maintaining it.
Per project and across the practice
Every register exists twice: inside the job, where the work happens, and across the practice, where a director can see all open RFIs at once without opening eleven projects.
Same records, two magnifications. That is the same idea the Brain applies to projects.
Common questions
What is an RFI register?
A Request for Information register records the formal questions raised during construction, who raised them, when a response is due, and what was answered. In architecture it matters because an unanswered RFI is a programme risk and, often, the origin of a variation.
Does Mudo handle variations?
Yes, as their own register with a commercial consequence rather than as notes. A variation records the change, what it affects and what it is worth, which is what allows the fee position to reflect it rather than being reconciled at the end.
Can I see registers across all projects?
Yes. Every register exists inside the Project Pod and also practice-wide, so a director can see every open RFI across the practice without visiting each job.
What this page is based on
Every capability described here was checked against the running application before publication. These are the parts of it you can open for yourself.
- /registers/actions, /registers/decisions, /registers/rfisThe practice-wide registers, reachable in the application.
- /projects/:projectId/variationsPer-project variations register, alongside rfis, issues, deliverables, risks, actions and decisions.
Stop finding out what the practice owed at handover.
- Drawing review
- Client, consultant and builder portals
- Contract administration
- The Project Pod
- Fees and variations
Free for solo practices: one user, two projects, no card.