The Four Settings That Decide Whether Your Custody Record Is Evidence
A custody record that says "issued to J. Otieno" settles nothing. One with an approver, a location and a verification date settles most things. Four settings decide which you have — and the default for the most important one gates nothing at all until you configure it.
The generator is not at the Naivasha site. It was moved, everyone agrees, and there the agreement ends. The register says it was transferred there in February by a user account that belongs to somebody who has since left. No approver, no coordinates, and last verified — according to the field that exists for exactly this — never. Nobody is lying. There is simply nothing in the record capable of settling the question, which is a different and more common problem than dishonesty.
The controls that would have settled it all exist. They are configuration, most of them are off or empty by default, and one of them looks like protection while providing none. That is worth walking through precisely, because custody discipline is only as good as what the system actually enforces.
The approval chain, in the order it is evaluated
Whether a movement needs approving is decided by four tests in sequence. Reading them in order explains a great deal of otherwise surprising behaviour.
| # | Test | Effect |
|---|---|---|
| 1 | Is this specific asset flagged as requiring approval? | If yes, approval is required — and this overrides everything below, including an organisation-wide setting of "no approvals". A per-asset flag cannot be switched off globally, which is the correct precedence and occasionally a surprise. |
| 2 | Is this action in the approval-actions list? | If not, no approval, regardless of mode or risk. The default list is checkout, transfer, relocate and retire — so check-in, verification, maintenance moves and damage or loss marking are ungated by default. |
| 3 | What is the approval mode? | Three options: none (nothing gated), all movements (every listed action gated), or high risk only — the default, which defers to the fourth test. |
| 4 | Does the asset match your high-risk policy? | True if its risk level is high or critical, or its purchase cost is at or above your value threshold, or its category is on your high-risk category list, or its asset type is on your high-risk type list. |
Now read the defaults against that chain, because the interaction is the point. The mode defaults to high risk only. The value threshold defaults to unset. The high-risk category and type lists default to empty. Asset risk level defaults to standard.
Out of the box, "approval for high-risk movements" gates nothing — because nothing has yet been defined as high-risk.
The default worth knowing
This is not a defect; a system cannot guess that vehicles matter more than staplers, and defaulting to gating everything would make the first week unusable. But it does mean the setting reads as a control while being inert, and the fix takes about two minutes: set a value threshold, or list the categories that matter. Do that and it becomes the control it appears to be.
One useful behaviour follows automatically. When you register an asset that matches your high-risk policy, its risk level is promoted to high at creation. Set a threshold of, say, KES 200,000 and every future vehicle, generator and machine arrives flagged without anybody deciding. Assets registered before you set the policy are not retroactively promoted, though — so set the policy early, or sweep the existing register once afterwards.
Four GPS switches, independently
Location capture is not one setting. Check-out, check-in, transfer and verification each have their own switch, all off by default, plus an optional maximum accuracy in metres that rejects a reading too vague to mean anything. Movements also carry the scan event that produced them, when a movement came from a scan rather than a form.
Independence is what makes this usable. The instinct is to turn all four on and the result is a rebellion, because requiring coordinates for every routine check-in inside one office is friction with no evidential value. The pairing that earns its keep is transfer and verification: a transfer is the movement people dispute, and a verification claim without a location is the one that gets made from a desk.
Would your custody record survive being questioned?
Six criteria. Score honestly against what your register actually contains today, not what it could contain.
A named custodian, not a department or a location
Make them prove it: Pick any asset and ask who is accountable. If the answer is "the workshop", nobody is — and a place cannot be asked to return anything.
An approver distinct from the person who moved it
Make them prove it: Look at the last five transfers of your most valuable assets. Do any carry an approver? If the mover and the approver are the same person, it is a record rather than a control.
A recent verification date
Make them prove it: Sort by last-verified and look at the oldest. The field exists per asset with the verifier recorded; the question is only whether anybody has been using it.
Coordinates on transfers
Make them prove it: Was the asset recorded as arriving where it was said to arrive? Without this, a transfer to a site is an assertion typed from anywhere.
An expected return date on anything issued out
Make them prove it: Is there anything checked out with no return date? Those are the items that quietly become permanent, and reminders cannot fire without a date to fire against.
A condition recorded at both ends of a movement
Make them prove it: When something comes back damaged, can you show it left in good condition? Movements carry condition before and after; the argument only exists if the fields are blank.
Questions worth asking of any asset system, including this one
What to ask before you trust a custody trail
Can a movement be approved by the person who initiated it?
What a good answer sounds like
Approver and performer are recorded as separate fields, and your policy says who may approve.
Why it matters
Separately recorded fields make self-approval visible and auditable. Nothing here structurally forbids it, so it is a policy you set and then check — which is why the second scorecard row asks you to go and look.
What happens to a rejected movement?
What a good answer sounds like
It is retained with the rejecter, the timestamp and a reason — not deleted.
Why it matters
A refused transfer that leaves no trace is a missing half of the story. Rejections here are recorded with a reason, and the pattern of what gets refused is often more informative than what gets approved.
Is verification a movement or a note?
What a good answer sounds like
A first-class recorded action, with the asset carrying a last-verified date and verifier.
Why it matters
Verification recorded as a note is unqueryable, so "what have we not seen in a year?" becomes unanswerable. As a recorded action with a date and a name, that question is a filter.
Can the system tell me what is overdue for return?
What a good answer sounds like
An expected return date per movement, with a reminder lead time.
Why it matters
Custody without a return date is a gift. There is a configurable default custody period and a reminder window, defaulting to three days — but if the date is blank, nothing can be overdue.
Does a scan prove presence?
What a good answer sounds like
Only with coordinates and an accuracy limit; otherwise it proves a barcode was read.
Why it matters
This is the honest answer everywhere, and worth saying plainly. A scan without location says somebody had access to the label. With GPS required and an accuracy ceiling, it says something much closer to presence.
What AWRA OpsHub does today
- Three approval modes — none, high risk only, all movements — with a per-asset override that takes precedence over all of them.
- A configurable list of which actions require approval, defaulting to checkout, transfer, relocate and retire.
- High-risk determination by value threshold, category list, asset type list, or an explicit risk level of high or critical.
- Automatic promotion of a new asset to high risk when it matches your policy at registration.
- Movements retained in pending, approved, rejected, completed or cancelled states, with approver, rejecter, timestamps and a rejection reason.
- Twelve distinct movement actions including verification, maintenance in and out, and marking lost or damaged.
- Independent GPS requirements for check-out, check-in, transfer and verification, plus an optional maximum accuracy in metres.
- Latitude, longitude and the originating scan event stored on each movement, individual or pooled.
- Condition before and after on every movement, an expected return date, and a configurable reminder lead time defaulting to three days.
- Last-verified date and verifier held per asset.
What it does not do
- No prevention of self-approval. Performer and approver are separate fields, so it is visible and reviewable — but nothing structurally stops one person doing both.
- No approval routing by value band or role. Approval is required or not; who may approve is a permissions matter rather than a threshold-based escalation chain.
- No retroactive risk promotion. Setting a high-risk policy flags future registrations, not the register you already have.
- No geofencing — coordinates are recorded and never checked against an expected boundary, so a transfer logged from the wrong town is captured but not questioned.
- No verification schedule or overdue-verification alerting; the date is recorded and nothing chases it.
- No photo capture on issue or return, which is the evidence most useful in a condition dispute.
- No offline movement capture, so a site with no connectivity records the movement later, from somewhere else.
- The high-risk default gates nothing until you set a threshold or list categories.
Two of these deserve pairing in your head. Coordinates are recorded but never validated against an expected location, and there is no overdue-verification alert — which together mean the raw material for good evidence is captured while the checking remains human. That is a fair position for a system to take, provided somebody actually does the checking. Put both into a quarterly review and the gap closes; leave them and you have a well-populated register nobody has interrogated.
The single cheapest improvement
Set a high-risk value threshold. One number, entered once. Below it, movements stay frictionless and your team is not fighting an approval queue over keyboards. Above it, every check-out, transfer, relocation and retirement needs a second name — and new registrations above the line arrive already flagged, so the control extends itself as the register grows without anybody maintaining it. Almost every asset dispute worth having an argument about involves something above whatever threshold you would have chosen.
Our take
Know that the default gates nothing: approval mode is high risk only, and with no value threshold and no category list, nothing qualifies as high risk. Setting a threshold is the two-minute change that turns a setting which looks like a control into one, and it makes future high-value registrations self-flagging — then sweep the existing register once, since promotion is not retroactive. Turn GPS on for transfer and verification only, with an accuracy ceiling, because those are the two claims people dispute and the other two are friction without evidence. Set a default custody period so no issue leaves without a return date. Then accept what remains human: nothing prevents self-approval, coordinates are never checked against where the asset was supposed to go, and nothing chases an overdue verification. The record will be good enough to answer the question. Somebody still has to ask it.
Custody records that hold up
Approval by risk band with a per-asset override, approver and rejecter recorded with reasons, independent GPS requirements per action with an accuracy ceiling, condition captured at both ends, and last-verified date and verifier per asset.
See plans & pricingFrequently asked questions
Which asset movements require approval by default?
In practice, none — and this is the most important thing to know. The mode defaults to "high risk only", but the value threshold is unset and the high-risk category and type lists are empty, so no asset qualifies as high risk until you configure one of them. The setting reads as a control while being inert. Setting a value threshold takes two minutes and fixes it.
What counts as a high-risk asset?
Any one of four things: an explicit risk level of high or critical, a purchase cost at or above your value threshold, a category on your high-risk category list, or an asset type on your high-risk type list. Assets registered after you set a policy are promoted to high risk automatically if they match it — but existing assets are not, so sweep the register once after configuring.
Which actions can be gated?
The approval-actions list defaults to checkout, transfer, relocate and retire. Check-in, verification, maintenance moves and marking something lost or damaged are ungated by default. The list is configurable, and an action not on it needs no approval regardless of mode or risk level.
Can someone approve their own movement?
Nothing structurally prevents it. Performer and approver are recorded as separate fields, so self-approval is visible and reviewable rather than hidden, and who may approve is governed by permissions — but there is no rule that forces two different people. Treat it as a policy you set and then verify by looking at your last few high-value transfers.
Should we require GPS on all movements?
No. The four switches are independent for good reason: requiring coordinates for a routine check-in inside one office is friction with no evidential value, and blanket enforcement produces workarounds. Enable it for transfer and verification, which are the two claims people actually dispute, and set a maximum accuracy in metres so a vague reading is rejected rather than recorded as fact.
Does the system check that an asset arrived where it was supposed to?
No — there is no geofencing. Coordinates are captured and stored on the movement, and they are never compared against an expected location, so a transfer logged from the wrong town is recorded faithfully and not questioned. Likewise nothing chases an overdue verification. The raw material for good evidence is captured; the interrogation is a quarterly review somebody has to actually do.
