TRACE

AI Video of team work
TRACE
Obsidian relationship map
Connect to alibaba cloud
Page UI
UI
chatbox

Inspiration

We're both BIM specialists in the AEC industry, and we keep watching the same failure play out in our daily work.

The industry is very good at recording what was decided. It is almost never good at recording why. A material choice, a structural system, a fire strategy — each one gets agreed in some meeting, then carries a project forward for months, sometimes years, resting on assumptions nobody writes down: that the building stays above 18 metres, that the budget holds, that a planning condition doesn't shift. Those assumptions live in email threads, in minutes nobody rereads, in the heads of people who've since moved on to another project.

Every AEC professional has seen how this ends: a decision from January gets quietly undercut by a value-engineering call in March, and nobody notices the connection — not because anyone was careless, but because nothing in the process actually watches for it. The contradiction surfaces later as an RFI, a change order, a rejected submission, or, in the worst case, a safety failure.

We've each lived this from a different side — one of us trying to structure information that was never captured in a structured way to begin with, the other making decisions that would later need explaining and defending, sometimes to people who weren't in the room. TRACE is what we built, because it's the gap we understand best.

What it does

TRACE is an AI-powered memory agent for the AEC design process. It does four things, and as far as we can tell, nothing else out there does all four together.

It captures decisions as structured memory. Feed TRACE a meeting transcript and it pulls out every decision that was actually made, not just what was agreed, but who agreed it, when, why, and what assumptions it's standing on. Each one becomes a record: statement, rationale, assumptions, author, discipline, RIBA stage, timestamp. That "why" layer is the thing the industry has always dropped on the floor.

It catches conflicts the moment they happen, unprompted. Every new decision gets checked against everything already on record. If it quietly breaks the premise an earlier decision depended on, TRACE fires an alert right then: which decision just broke, why, and the blast radius, meaning every downstream system, submission, or decision now in question. Think of it as clash detection's temporal cousin. Clash detection catches two objects occupying the same space right now. TRACE catches a new decision undermining an old one across time.

It recalls the right decisions inside a tight budget. Ask "why did we pick this cladding, and can we still change it?" and TRACE pulls back only what's currently valid, ranked by relevance, recency, and importance, packed into a token budget you can actually see. If nothing's on record, it says so. It doesn't guess.

It keeps the full history, always. Nothing gets deleted. A superseded decision is marked superseded, timestamped, linked to whatever replaced it, and stays queryable forever. That's the golden thread: an attributable, timestamped record of every decision a project ever made.

Geometric clash detection asks one question: do two objects occupy the same space right now? TRACE asks a different one: does this new decision break an assumption an old one was relying on? It's not a search box waiting for someone to open it. It's automation that pushes the alert into the conversation the second it matters.

How we built it

We built the whole four-part loop test-first: 111 offline tests, TDD the whole way, on the Qwen stack. The foundation is a bi-temporal SQLite store that never deletes, backed by a SHA-256 hash-chained audit log. Qwen-plus does the capture, using function-calling to pull each decision's statement, rationale, and assumptions straight out of a transcript. The invalidation alert is gated by a deterministic rule-pack built from actual fire-safety code clauses. It only falls back to an LLM premise-check when the rule-pack has nothing to say, which is what keeps it honest enough to demo live. Genuine conflicts get argued out by a three-role Qwen "decision court" (Proposer, Guardian, Judge) that actually rules on the case rather than just flagging it. Recall blends lexical overlap with Qwen text-embeddings, packed to a token budget, and abstains honestly when there's nothing to say.

Everything is exposed two ways: as Qwen-Agent MCP tools, and as a standalone, keyless MCP server, deployed on Alibaba Cloud's DashScope endpoint.

Challenges we ran into

We didn't trust our own testing, so about a week before submission we ran TRACE through a five persona AI council: five independent reviewers, each briefed to argue like a skeptical judge, cross examining the codebase and each other across multiple rounds.

That adversarial process is how we caught a real bug, not a hypothetical one. Our bi-temporal store was returning an empty result for a specific retroactive scenario: a decision recorded on one date, then superseded later with a backdated effective date. Ask "what did we know as of a date in between," and the store said nothing was on record at all, which is exactly the wrong answer for a system whose whole pitch is proving what was known and when. We fixed the query, wrote a regression test for that exact scenario, and reran the council. The score moved from 6.5 to 7.0.

The other real challenge was infrastructure, not algorithms. This was our first time standing up a full backend on Alibaba Cloud, and getting Qwen's endpoints, structured outputs, and long-context retrieval to actually cooperate took genuine trial and error, including tracking down a chain of undeclared dependencies at an hour we're not proud of. Classic hackathon problem, just not the one we expected to spend time on.

Accomplishments that we're proud of

We shipped the entire four-part loop end-to-end and test-driven, not a slide deck pretending to be a product: capture, active premise-invalidation with a real decision court, recall-to-budget, and bi-temporal time-travel, all backed by 111 offline tests. That's a working system, not a pitch.

What we're proudest of is that "never delete, only supersede" isn't a tagline for us. It's enforced. Every decision writes into a SHA-256 hash-chained audit log that any MCP client can go verify independently, no trust required. In Singapore, a Qualified Person carries personal criminal liability for what gets built under section 9 of the Building Control Act. That's not an abstract compliance box; it's a QP's name on the line. TRACE gives them something concrete to stand on: a record of every decision, every reason it changed, and proof that none of it was quietly rewritten.

What we learned

Going in, we assumed the hard problem was AI reasoning: getting a model to actually notice a contradiction. It wasn't. The hard problem was admitting that "we detect conflicts" isn't novel on its own; ADRs and plenty of generic knowledge-base tools already do that. What's actually defensible is the specific combination: an AEC-aware decision-dependency graph with active premise-invalidation, shipped as automation that pushes the alert to you rather than a tool you have to remember to open. That reframing changed how the two of us think about our own day jobs, too. The gap was never really a documentation problem. It was a memory problem the whole time.

What's next for TRACE

Two concrete next steps. First, turn the desktop watcher into an actual plugin for the tools AEC teams already live in: Revit, Acrobat, Outlook, Teams. That way decisions get captured as meetings happen, not uploaded as a transcript afterwards. That's what makes "ambient capture" frictionless in real practice instead of one more thing to remember to do.

Second, pilot TRACE on a live Singapore project with a practising QP, and use that to grow the rule-pack past SCDF fire clauses into BCA structural and URA planning conditions, so the same decision-court logic holds up against a real submission, not just our demo transcripts.