Triora

The Sentence That Stopped Us

The first time we read Kaya's challenge brief, one sentence stopped us mid-scroll: "Nobody has good answers and delays cascade into missed schedules and blown budgets." Not the problem statement. The confession buried inside it. An AI-native construction supply-chain company, one that's already coordinating billions of dollars of active projects, was openly saying that even with full visibility, nobody actually knows what to do with it. That's not a data problem. We'd seen dozens of hackathon briefs frame "the industry lacks visibility" as the opening line. This one was different. It admitted visibility already exists, and it still isn't enough. So we asked a different question than the one on the page. Not "how do we track materials better?" but "why does more tracking keep failing to produce better decisions?"

What Forty Red Flags Taught Us

We started by imagining the dashboard nobody wants to open on a Monday morning. A mid-size project easily tracks over a hundred material packages. On any given week, dozens will show some kind of delay signal, a vendor email, a missed submittal date, a shipment running behind. A conventional tracker turns every one of those into a red flag. And that's precisely the failure mode: when everything is flagged, nothing is prioritized. The project manager either burns hours triaging manually, or, more realistically , starts ignoring the flags altogether, because experience has taught them most of them don't matter. That's not a UI problem. It's alert fatigue, and it has a name in fields that deal with it well. Emergency medicine doesn't treat patients in the order they arrive. It triages by urgency, because when everyone is technically "at risk," someone has to decide who actually needs attention first. Nobody was applying that logic to construction materials.

The Question We Decided to Answer Instead

Somewhere in that reasoning, the real insight crystallized, and it's the one thing everything else in this project is built around: Delivery delay is not the same thing as project delay. A material that arrives ten days late might cost nothing, if the schedule has ten days of float to absorb it. A material that's only two days late can halt commissioning, if it sits with zero float on the path feeding a downstream milestone. Existing tools can't tell these two cases apart, because they're both answering the same shallow question, is this late? instead of the question that actually determines outcomes: does this lateness reach anything that matters? Once we saw it that way, we stopped thinking about this as a tracking problem and started thinking about it as a triage problem. That reframe is the entire reason Triora exists. We should say plainly why we reached for this framing instead of the more obvious one. We're studying in one of the first undergraduate batches of Industrial Engineering and Operations Research at our institute- a young department, still defining what it means to bring OR into modern, AI-native problems. That background shaped our instinct immediately: don't just predict a delay, characterize where it sits in the system. Float, critical path, dependency structure, these are decades-old operations-research ideas, and it struck us as strange that nobody had put them next to modern delay-prediction AI. That gap felt like ours to close.

Building Around Consequence, Not Status

We designed Triora's core mechanism around a single score, one we call the Criticality-Weighted Risk Score: $$ \text{CWRS} = P(\text{delay}) \times \left(1 - \frac{\text{float}}{\text{lead time}}\right) \times \text{downstream blast radius} $$ captures how likely a material is to miss its need-by date. The float term captures how much schedule slack exists to absorb that lateness before it matters, this is the term most tools skip entirely, and it's the one that turns a naive "late" list into an honest "critical" list. The blast-radius term captures how many downstream activities and milestones actually depend on this material, pulled from a dependency graph connecting materials to the construction schedule. We built this as a working prototype: a project schedule modeled as a directed graph, critical-path float computed properly rather than assumed, and CWRS applied across a realistic set of tracked materials. The result is not a hypothetical, running it against a synthetic but mechanically honest project produced exactly the pattern we'd predicted. Out of over a hundred tracked materials, only a couple carried genuine project-level risk. Several materials that looked alarming under a simple "is it late" view — because they were, in fact, late, turned out to sit on activities with enough float that the delay never reached the critical path at all. That contrast is the proof of the whole thesis, and it's something we could point to rather than just argue for.

What We Chose Not to Build Yet

We were deliberate about scope. It would have been easy to claim a fully autonomous pipeline, document intelligence pulling structured events out of vendor emails, Bayesian updating as new evidence arrives, an optimizer recommending recovery actions. We propose all three as the next layers of this system, and we designed the architecture with them in mind. But for this stage, we chose to prove the mechanism that actually differentiates Triora, the graph-and-float-based triage logic, rather than gesture at five layers we hadn't tested. That was its own intellectual challenge: deciding what the AI should actually optimize for. It would have been simpler to optimize for prediction accuracy, "will this be late, yes or no." We optimized for something harder to get right and more useful once it is: which risks, out of everything flagged, deserve a human's attention this week. That's a ranking and consequence problem, not a classification problem, and it pulled us toward operations-research thinking, critical path method, dependency graphs, schedule slack, as much as it pulled us toward AI. We also had to decide, early, what kind of company this could be. It would be easy to build something that quietly competes with the platforms, Kaya, Procore, Primavera, that already do the visibility work well. We designed Triora instead as a decision layer that sits on top of that visibility: it doesn't replace the tracker, it answers the one question the tracker was never built to answer.

What This Taught Us

Working through this project changed how we think about applying AI to operational problems generally. It's tempting to treat "AI system" as synonymous with "prediction system." But in a domain like construction, where the cost of being wrong is measured in missed milestones and blown budgets, a good prediction that isn't connected to consequence is just a more sophisticated red flag. The harder and more valuable problem is connecting probability to structure, knowing not just what might go wrong, but where it actually reaches. It also taught us something about our own field. Operations research has spent decades solving exactly this class of problem, scheduling, resource allocation, risk under uncertainty, usually behind the scenes, in ERP systems and spreadsheets nobody sees. Being early students in a department still finding its footing means we don't yet have a settled playbook to follow. We had to figure out, from first principles, how classical OR ideas like float and critical path actually meet modern AI. We think that's exactly the kind of contribution our generation of OR students is positioned to make to supply chain: not reinventing the mathematics, but finally pairing it with the AI layer that lets it act on messy, real-world, real-time data.

Where This Goes

If we build this out completely, we don't think it stays a standalone tool. We think it becomes the layer that every project's existing tracking software plugs into, the thing that takes a hundred-and-thirty-seven flags and turns them into a two-item list a project manager can act on before their coffee gets cold. Extended across a portfolio, the same graph logic that identifies a single project's critical risks can identify when one site is expediting a material that another site already has sitting in surplus. This isn't another AI dashboard. It's a different question, asked of the same data everyone already has: not what's happening, but what actually matters, and what to do about it before it's too late.