Rangka

Construction delay and potential claim evidence

When a delay becomes important, the supporting evidence should already be connected.

Rangka keeps a reported issue with its source, project date, related activity, and later PM decision. The team can retrieve the chronology when it needs to prepare internal or client-facing supporting information.

See the worked example
  • Original source stays connected
  • Entitlement remains a professional decision
Delay chronology · Block A pumpsEntitlement not assessed
What the site reported

“Pump delivery did not arrive on the reported date. The team recorded the affected work front.”

Message + delivery record + photo
Prepared for review
Reported event
Pump delivery outstanding
Evidence date
18 September 2026
Programme effect
Separate review required
The source and reviewed fact stay connected for later contractual assessment.

The daily problem

A delay record loses value when its context is scattered.

A message may state the reason, photographs may show the condition, and the programme discussion may happen later. Keeping those sources connected makes the chronology easier to review without turning software into a contract administrator.

What was reported

Retain the original message, sender context, timestamp, and available media.

What the PM accepted

Keep the prepared interpretation separate until the PM corrects or approves it.

What changed later

Trace the later report or programme decision without rewriting the original source.

A different worked project example

Follow the anchor-bolt delay from source to decision.

This is an illustrative product scenario, not a real claim or a statement of contractual entitlement.

  1. Reported issue

    Two pipe supports waiting for anchor bolts at Grid B2.

  2. Connected evidence

    Site photographs and a delivery note remain attached to the project day.

  3. Reviewed fact

    The PM-approved record preserves the reported reason and supporting source references.

How the workflow works

Build the chronology before someone asks for it.

The same controlled record supports daily visibility and later retrieval. Programme impact remains a separate review when suitable programme data exists.

  1. 1

    Capture the reported event

    Keep the message, date, location, reason, and available media together.

  2. 2

    Review the prepared facts

    The PM corrects or rejects unsupported interpretation before approval.

  3. 3

    Retrieve the evidence set

    Return to what was reported and approved when preparing a delay record or client response.

Where human judgement remains

Rangka organises evidence. Your project team determines its contractual use.

Rangka helps organise and retrieve potential claim evidence. It does not determine contractual entitlement or approve a claim on behalf of your project team.

Continue from here

Use the guide or working tool beside this workflow.

Questions before you start

Clear answers about this workflow.

Does Rangka detect a valid claim?

No. It surfaces reported delays and evidence; entitlement requires contractual and professional assessment.

Does it approve a claim?

No. Rangka does not approve a claim on behalf of the project team.

Can a programme change automatically?

No. A supported simulation is reviewed separately and never silently changes approved dates.

Start with your first active project.

Create a free Rangka workspace.

Your PM stays responsible for every approved record.