Repeat-issue clustering.
The same problem, raised eleven times, in eleven places, by eleven people who each thought it was theirs. Individually each is a small item. Together they are a design fault, and only the cluster shows it.
Zepth Core · Site Operations
Issues
Nothing raised gets lost. Everything ageing escalates. That is the whole job.
Last updated
Zepth Core module
Issues
AI agent built into the module
Frictionless captureNamed ownership and datesAgeing dashboards with rule-based escalationResolution into the right instrument
Overview
The issues log is a project’s working memory: the coordination clash, the access conflict, the missing dimension, the thing somebody noticed and said out loud. Everything that needs fixing or deciding but does not yet warrant formal machinery.
Its job is simple, and it is almost never done. Nothing raised gets lost. Everything ageing escalates.
Where issues sit on the ladder
The site already publishes an escalation ladder, and this page uses it rather than inventing a second one: an observation, fixed and photo-verified. Repeated or ignored, and it becomes a site instruction directing correction. Confirmed as actual non-compliance, and it becomes an NCR. Unresolved at handover, and it blocks completion.
An issue sits below all of that — informal, fast, and cheap. And that is not a weakness; it is the point. The issues log is where most problems SHOULD die quietly, having been raised, owned and fixed, without ever consuming a formal instrument. A project where everything becomes an NCR has not achieved rigour. It has achieved a paper war, and the people fighting it have stopped looking at the building.
What makes the ladder work is the triggers — the published rules that move an item up it. A ladder applied by mood produces both failure modes simultaneously: paper wars, where everything escalates, and buried problems, where nothing does. Write down the rungs, and write down what moves an item between them.
Ownership and ageing are the entire discipline
An issue without an owner and a date is not an issue. It is a future dispute with a timestamp on it, and the timestamp is the part that will be read out.
So: a named person, never a company or a discipline. A date. And a weekly review that looks at the log by AGE rather than by status — because status is what people report and age is what is true. An item that has been open for sixty days is telling you something regardless of what its status field says, and what it is usually telling you is that its owner cannot resolve it and has not said so.
That is the escalation trigger, and it should fire by rule. Ageing past a threshold moves the item up, whether or not anyone feels like escalating it — because the reason an item ages is very often that escalating it would be awkward.
Issues are born everywhere and die in the wrong place
They come out of meetings as actions. Out of walks as observations. Out of coordination reviews as clashes. Out of a phone call as a promise.
And they resolve into other instruments — a fix, an RFI, a site instruction, an NCR — which is exactly where they get lost, because the moment an issue becomes an RFI, the issue is typically closed and the RFI is tracked somewhere else by somebody else. Two systems, one problem, and a gap between them precisely where the handover happens.
The linkage is what stops the evaporation. An issue that spawned an RFI stays visible until the RFI is answered, not until the RFI is raised. Otherwise the log tells you the issue was resolved, and it means the issue was forwarded.
The value
Why it matters
Nothing raised gets lost, because capture is fast enough that people actually use it.
Ageing items escalate by rule rather than by whoever is willing to have the awkward conversation.
Most problems die quietly at the cheapest rung, instead of becoming a formal instrument and a paper war.
An issue that became an RFI stays visible until the RFI is answered — so “resolved” cannot quietly mean “forwarded”.
Capabilities
What you can do
01
Frictionless capture
A photo, a location, one line. Friction is what determines whether the log records the issues, or only the issues somebody had time for.
02
Named ownership and dates
A person and a date on every item — because a company cannot be asked why something is sixty days old.
03
Ageing dashboards with rule-based escalation
Review by age, not by status. Escalation fires on the threshold rather than on somebody’s willingness to raise it.
04
Resolution into the right instrument
Into a fix, an RFI, an instruction or an NCR — with the thread kept, so the issue closes when the instrument is answered rather than when it is raised.
The workflow
How it actually runs
- 1
Capture fast — a photo, a location, one line
Friction is the enemy here more than anywhere else on the project. An issues log that takes two minutes to fill in is an issues log that records the issues somebody had time for.
- 2
Assign an owner and a date
A person, not a company. An issue without both is a future dispute with a timestamp on it.
- 3
Review by age, weekly
Not by status. Status is what people report; age is what is true. And ageing past the threshold escalates by rule, because the reason an item ages is often that escalating it is awkward.
- 4
Resolve into the right instrument — and keep the thread
A fix, an RFI, an instruction, an NCR. And the issue stays open until the instrument it became is answered. Otherwise “resolved” means “forwarded”.
AI that does the work
How AI changes Issues management.
Escalation candidates.
Items that have met a published trigger — repeated, ignored, aged past the threshold — surfaced by rule, so escalation stops depending on somebody being willing to have the conversation.
The weekly ageing review, drafted.
Written from the log itself: what aged, what escalated, what closed, and who has the oldest item on the project.
The engineer’s judgment stays in charge; the AI removes the latency and the blind spots.
Best practices
- Make capture take fifteen seconds. Every second of friction filters out a real issue, and the ones filtered out are the ones nobody thought were important enough to type — which is not the same as unimportant.
- Review the log by age. Status is a report; age is a fact. Anything sixty days old is telling you its owner cannot resolve it and has not said so.
- Escalate by published trigger, not by mood. A ladder applied by feeling produces paper wars and buried problems at the same time.
- Let issues die at the issue level. A project where everything becomes an NCR has not achieved rigour — it has achieved a paper war, and the people fighting it have stopped looking at the building.
Dashboards & reporting
The log by age, by owner and by zone — with age leading, because status is what people report and age is what is true. Escalation candidates against the published triggers. Repeat clusters, which is where a design fault hides as eleven small items. And the resolution thread: which issues became RFIs, instructions or NCRs, and whether those have actually been answered — because until they are, the issue is forwarded rather than resolved.
Live dashboards
Drill-down & filters
Export to Excel / PDF
FAQ
Common questions
Issue, observation, NCR or snag — which is which?
An issue is the informal, fast layer: raise it, own it, fix it. An observation is a recorded condition, fixed and photo-verified. Repeated or ignored, it becomes a site instruction. Confirmed as actual non-compliance, it becomes an NCR. A snag is a minor defect at or near completion. Worth being honest: this taxonomy is convention rather than code, and it varies by project — which is exactly why you should publish your own definitions and your own escalation triggers.
Read the full answerWho should own an issue?
A named person, with a date. Never a company and never a discipline — “the MEP subcontractor” cannot be asked why an item is sixty days old, cannot be escalated to, and cannot explain itself. An issue without an owner and a date is not an issue; it is a future dispute that has helpfully recorded the date on which you knew.
When does an issue become an RFI or an instruction?
By published trigger, not by judgement-of-the-day: typically on repetition, on being ignored past its due date, or when it turns out to need information or a direction nobody on site can give. And when it does escalate, keep the thread — the issue should stay open until the RFI is ANSWERED, not until it is raised. Otherwise your log will tell you the issue was resolved when what actually happened is that it was forwarded.
How do you stop an issues log becoming a graveyard?
Review it by age rather than by status, weekly, and escalate on a rule rather than on a feeling. A log becomes a graveyard when items can sit at “in progress” indefinitely without anything happening to them — and they can do that because nobody is looking at the age column, and because escalating somebody else’s stale item is socially expensive. Make the rule do it instead.
Read the full answerSources
- The escalation ladder on this page is the site’s canonical one, published on /modules/site-observations/ and in the quality-escalation-ladder answer. It is reused here rather than restated as a second, competing version.
- This page carries no stat band. There is no defensible published benchmark for issue-log hygiene, and we would rather say so than invent one.
Related modules
Related answers
Zepth is the construction project delivery platform — it runs construction, procurement and asset management on one record, and does the work: reading the drawings, reviewing the submittals, matching the invoices and flagging the risks, with a human sign-off on anything consequential.
See it on your project.
A short, tailored walkthrough on your real workflow — no generic demo.