Delays and notices
When the job slips, the record is already there.
The paperwork that settles a delay is written months before anyone calls it a delay. Brikt builds that record while the job runs, out of the blockers your team is already raising — so the answer to “when did you first know?” is a date, not a reconstruction.
Delay records
Delay records built from the blockers your team already raised.
Blockers are raised in the field, at the moment the lateness is realised, against a schedule anchor Brikt validates rather than trusts. When one turns out to be a delay, it is promoted into a delay record — not retyped into a second system a week later, from memory.
The record keeps what was known when: the activity, the anchor, who raised it, and the days it ran. That chain is the difference between a delay you can explain and a delay you can only argue about.
Candidate detection
Brikt notices the slip. It does not file it for you.
Activities drifting past a threshold you set are surfaced as candidates on the delays page. A candidate is a suggestion with two answers: this is a delay, or this is not.
Nothing is filed on your behalf
Detection suggests; a person records. There is no automatic delay, no automatic notice, and no queue of things the software decided while you were on site.
It remembers what you dismissed
Brikt records the first time it saw each candidate, so one you have already said no to does not come back and ask again every morning.
It says when it cannot tell
With no active baseline there is nothing to measure drift against, and the page says so rather than reporting a confident zero.
Recovery plans
Write down what you are going to do about it.
A delay record carries the recovery plan beside it — what the team intends, recorded where the delay is, instead of in an email nobody can find in October.
A recovery plan is a written record. It does not move a date on its own; if the plan changes the schedule, somebody changes the schedule, and that edit is logged like any other.
Delay impact notices
A notice, drafted for your team to review.
A delay impact notice is drafted from the record — what happened, which activities it touched, and what it does to the finish date. It arrives as a draft, and it stays a draft until people who are accountable for it decide otherwise.
Drafted
Composed from the delay record, with the schedule impact computed rather than asserted.
Reviewed and approved
The project team reads it, edits it, and approves it. Nothing leaves Brikt on its own.
Issued and frozen
Once issued the notice is frozen as a numbered instrument. The document on file is the document that was issued — not a re-render that has quietly moved on.
Brikt helps project teams plan, manage, document, and communicate construction schedules. Final review and responsibility for every schedule, narrative, notice, and report remain with the project team.
The record you wish you had kept.
Bring a job with a slip you are still living with, and we will show you what the record would have looked like.