Mace

The bespoke-per-project approach is gone. Every project now uses the same template, the same review workflow, the same reporting structure — regardless of whether the contractor is on Viewpoint, ACC, Aconex, Asite, or Procore.

The compliance checking cycle that used to take information managers the better part of a day — extracting a report from the CDE, loading it into an Excel tool, compiling findings, sending them back, waiting for the next batch, repeating — now happens automatically in the background. On one project, the platform showed 97% submission compliance across 115 expected deliverable types, with only 4 types missing, updating in near real-time as the contractor continued uploading. That level of visibility used to take hours of manual work each cycle. Now it’s the click of a button.

Reviewers no longer spend time navigating unfamiliar CDEs, searching through hundreds of documents, and guessing which revision is current. They open Morta, see their assigned items, click straight through to the right file on the CDE. The Lead TA can spot bottlenecks across all disciplines at a glance — no more chasing individuals for status updates.

Critically, none of this required contractor buy-in. Contractors don’t need to learn a new system, change their processes, or even know the platform exists. Everything still happens in their CDE. This eliminated the adoption barrier that typically kills client-side tooling on multi-contractor programmes.

The most telling sign of impact is what happened next. One of Jamile’s colleagues — a Lead TA on a different project — saw the review platform and asked whether derogation tracking could work the same way: items that keep getting derogated across multiple delivery teams flagged for escalation to the client. That conversation turned into a concrete plan to build a derogation tracker in the same hub. Other requests followed — review cycle analytics to understand which deliverable types need the most rounds, and an assurance report that pulls evidence of compliance directly from the platform instead of being compiled manually in Word.

As a technical advisor, Mace works client-side — accepting, rejecting, and reviewing deliverables on behalf of the client. The S5 review and acceptance workflow is the core of the job.

In an ideal world, every project on a framework would use one CDE. Everyone learns the system once. But that’s not the reality. In many frameworks, the main contractor’s CDE gets adopted as the project CDE. So across Mace’s portfolio, one project runs on Viewpoint, the next on Aconex, another on ACC, another on Asite or Procore. Each has different interfaces, different metadata structures, different workflows. Client-side reviewers had to learn each system from scratch, with very tight deadlines and no time for training.

The downstream effects were painful. There was no unified way to track review progress — some projects used spreadsheets, some relied on the CDE’s native reporting, some had nothing. The Lead TA couldn’t get a bird’s-eye view without manually aggregating data from multiple sources.

Compliance checking was entirely manual: go to the CDE, extract a report, run it through an Excel tool, compile the findings, send them back. If there’s another batch of uploads, repeat the whole cycle. And some CDEs didn’t even have adequate commenting tools, forcing reviewers into email threads and separate documents with no centralised audit trail.

There was also no way to track how many review rounds a deliverable needed before acceptance — so patterns couldn’t be spotted, recurring issues couldn’t be addressed proactively, and reviewer capacity couldn’t be allocated effectively.

The key insight was simple: don’t try to replace the CDEs. Build a guide layer on top of them.

Morta doesn’t replace Viewpoint or Aconex or Procore. All commenting, acceptance, and rejection still happens in the contractor’s CDE. What Morta does is give the client team one consistent interface that tells each reviewer exactly what they need to review, links them straight to the right file and revision on the CDE, and tracks what’s outstanding. Contractors don’t need to change anything — most don’t even know the platform exists.

The foundation was defining 9 core metadata fields that every CDE must provide: deliverable reference, filename, description, revision, is latest revision, status, organisation, last modified, and URL. The URL is the critical one — that’s the bridge back to the CDE. Different CDEs call the same fields different things (Viewpoint says “name”, Aconex says “document number”, Asite says “document ref”), so Adam Green built Python scripts with fallback logic that try each possibility in sequence. This made the template genuinely plug-and-play across CDEs.

On top of this, a reviewer matrix maps every deliverable type to the disciplines responsible for reviewing it. When deliverables arrive from the CDE, each reviewer sees only their assigned items with current revisions, a vote column, and a direct URL to the file. An empty vote cell means there’s a new revision they haven’t looked at yet. A history tab shows all previous revisions with their votes and comments.

The Lead TA gets a bird’s-eye view across all disciplines — filtering by “not started”, “waiting for comments”, or “rejected” to identify bottlenecks instantly, without chasing people for updates.

Before the review even starts, the platform compares the MIDP against the expected deliverables list — on one project showing that 70% of 115 expected deliverable types had been logged, giving the team a chance to coordinate missing items early. Once uploads begin, submission compliance updates in near real-time, with validation rules automatically catching project code typos, missing organisations, and metadata gaps.

For CDEs with inadequate commenting tools, Morta’s tabular format provides a structured fallback — maintaining a centralised audit trail instead of scattering feedback across emails. And the platform tracks how many revision cycles each deliverable needs before acceptance, surfacing patterns that were previously invisible.

The whole thing was built by two people: Jamile designed the solution architecture and workflow, and her colleague Adam Green wrote the Python scripts for metadata mapping. Jamile’s background is in architecture, but her focus on public sector work — where she sees real opportunity for change and visibility — shaped a solution designed for the messy reality of multi-contractor programmes.

The critical milestone was getting the 9 core metadata fields and their CDE-specific lookup tables right. Without that, nothing else — reviewer assignment, compliance checking, progress monitoring — would work consistently. There were brainstorming sessions between Jamile, Adam, and colleague Jad to figure out the best approach. The fallback logic in the Python scripts was the breakthrough that made the template truly reusable across CDEs.

Jamile’s advice for teams starting out: allow time for hiccups on the first CDE integration. There were situations where they couldn’t read data from a CDE, or metadata was labelled inconsistently in ways that broke the fallback logic. These had to be troubleshot against real data before things worked smoothly. But once the integration was working for one CDE, replicating for others was straightforward — only the mapping layer changes, the template structure stays the same.

The solution is still being trialled and refined across multiple projects. Each new deployment validates and tightens the approach further.