Nine Actions, and What They Prove
Twelve movement actions are declared in the code. Nine are written by something. The gap between those two numbers is where most custody claims live — and the page that got this right did so by listing what the service writes, not what the module is called.
A chain of custody is the only evidence that will ever exist about where a thing was. There is no ledger to reconstruct it from and no statement to reconcile against. If the event was not recorded when it happened, the fact is gone.
That makes the question of which events a system can record unusually consequential, and unusually easy to answer badly.
The nine
What each recorded action actually asserts
Action The claim it makes
Check-out A named person took it
The strongest record in the set, because it names a human being rather than a place. Everything else is geography.
Check-in It came back
Only meaningful as the closing half of a check-out. An unmatched check-out is the register's most useful exception.
Transfer It moved between locations
A change of custody without a change of holder. Distinct from a relocation, and the distinction is worth keeping.
Relocation Its home changed
Not where it is today but where it now belongs. Conflating the two is how a register loses track of what "should be here" means.
Verification Somebody physically saw it
The only action that asserts a present-tense fact about the object rather than about a movement.
Damaged Its condition changed
A condition event, not a location one, and the register carries both kinds without confusing them.
Lost It is not where it should be
The action most registers omit, which is why theirs grow a permanent tail of assets nobody will admit are gone.
Retirement It is out of service
A custody end, deliberately not an accounting one — no disposal gain or loss is computed anywhere.
Approval Somebody authorised a movement
The action that makes the other eight controls rather than notes, where a movement requires one.
Each row is written by a service in this codebase. That sentence is the whole standard being applied.
And the three
The model declares three more: sent to maintenance, returned from maintenance, and assigned. Nothing in the product writes any of them. For a period they were rendered into the movement-action filter on two screens, so a user could select an option that was guaranteed to return an empty table on every dataset that would ever exist.
The fix was to separate the declared list from the recorded list, and to render only the recorded one. The constants remain in the code because deleting them is a schema decision rather than a bug fix; what changed is that nobody is offered them any more.
Twelve declared, nine written. Every audit that greps for a name finds twelve. Only an audit that asks what writes it finds nine.
The audit that expected to find a disaster
This corpus once carried the widest copy defect anybody here has found — around thirty assertions across fifteen files, all describing service schedules, calibration dates, downtime records and plant utilisation that did not exist. When that was cleaned up, the product's own asset-tracking page was expected to be the worst single offender, because three of the corrected pages linked to it.
It was clean. No service-schedule claim, no calibration claim, no downtime claim, no utilisation claim. Its movement-log section listed exactly the nine actions the services write, and correctly omitted maintenance.
Whoever wrote it had gone and looked at what the code records instead of describing what an asset module normally does. That is the entire difference between an honest page and a dishonest one, and it is not a matter of intent — the people who wrote the thirty false assertions were not lying. They were describing the feature they assumed was there.
How to check a custody claim in ten minutes
Weight is how much of your confidence should rest on each answer.
Ask for the list of recorded actions
Make them prove it: A finite list, not a category
Filter the movement log by each one
Make them prove it: Every option returns rows on real data
Ask which of them require an approval
Make them prove it: A specific answer per action
Ask what a "lost" asset does to the register
Make them prove it: It stays, marked, rather than disappearing
Ask whether the log can be edited or deleted
Make them prove it: No, by anybody, including an administrator
Four questions about movement history
How many movement actions can this system record?
A good answer sounds like
A number, and they can list them.
What it actually means
A vendor who answers "everything" has not counted, and the count is the only thing that makes the log auditable.
Is there any action in the code that nothing writes?
A good answer sounds like
They know, and they say.
What it actually means
We had three. Every grown system has some. The answer that should worry you is a confident no.
Does a check-out name a person or a location?
A good answer sounds like
A person.
What it actually means
Location-only custody cannot answer the question that actually gets asked, which is who had it.
Can an administrator delete a movement?
A good answer sounds like
No.
What it actually means
A custody log an administrator can prune is a custody log that proves nothing about an administrator.
What AWRA OpsHub does today
- Nine recorded movement actions, each written by a named service, each carrying the actor and the time.
- A movement filter that offers only the nine, so no option can return a guaranteed-empty result.
- Full per-asset history, so the question "when was this last seen and by whom" is always answerable.
- Lost, damaged and retired as first-class actions, so exceptions have somewhere honest to go.
- Scannable labels, so recording a movement in the field is a scan rather than a search.
What it does not do
- Maintenance movements. Two constants exist and nothing writes them.
- An assignment action distinct from a check-out — the third dead constant.
- Any geolocation on a movement. A location is a place you configured, not a coordinate.
- Photographic evidence attached to a condition change.
- A chain-of-custody document or export designed for an auditor rather than for a screen.
Not ours, by choice
- The nine actions are a genuine strength of this module and we would defend them. The three dead ones were a real defect and were user-visible on two screens.
- A movement log does not make a register accurate. It makes it reconstructable, which is a different and lesser promise, honestly stated.
- Nothing here is Papua New Guinean. Port Moresby is here because equipment that leaves for a site genuinely may not be seen again for months, and the record made at the moment of departure is all there will ever be.
What is not built for Papua New Guinea today can still be built for you
Anything described above as not built is a statement about what ships in the standard product today — not a limit on what AWRA OpsHub can do in Papua New Guinea. Kenya's eTIMS integration and its maintained payroll engine exist because Kenyan clients needed them and commissioned them; neither appeared by itself. The same door is open here. If a fortnightly pay cycle, a PNG payroll engine, supplier compliance dates at payment time, a bank or mobile money feed, a statutory return format, a rule your own operation needs that the standard one does not have, or a link to a system you already run is what stands between you and a decision, tell us and we will scope it as a build — written spec, timeline and price — before you commit to anything.
A pay period that is not a calendar month
The first build here is not a tax pipeline, because there is no clearance regime to connect to — it is a payroll period that can be a fortnight. Today our payroll run is one calculation per organization, per calendar month, per country of work, enforced by a unique key on the table and assumed again in the timesheet lock, the period-end resolution, the attendance window and the run form. Papua New Guinea pays twenty-six times a year and twice a year a month needs three runs, so this is a data-model change rather than a setting, and we would scope it as one. Then salary and wages tax on fortnightly tables, and the statutory deductions, computed on live employee records.
Supplier compliance dates, banks and payments
An expiry-dated compliance status on the supplier record that the payment run actually reads, so a business payment to a supplier whose Certificate of Compliance lapsed last week is flagged before it leaves rather than found in a review — we hold the document today and do not act on it. Plus bank feeds and local payment rails wired into the Payments Register. We do not verify a certificate and never will; validity is the Commission's determination.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
Payroll and statutory returns
A Papua New Guinean payroll engine: fortnightly salary and wages tax tables, superannuation and the training levy computed on live records, with the twenty-sixth pay period of the year recorded as its own event rather than folded into a month that already has two.
Systems you already run
The accounting package, CRM, online store or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. No roadmap slide, and no pretending in a demo that something exists when it does not.
Tell us what you need integratedOur position
Ask any vendor to enumerate what their movement log records, then filter on each answer against real data. It takes ten minutes and it is the only test that separates a custody system from a page describing one. The version of that test we ran on ourselves found three options that could never return a row, and fixing those was worth more than any feature we shipped that week.
Count the actions
Nine is a small number and that is the point. A finite, enumerable, individually testable list is what makes a custody claim checkable at all.
Talk about chain of custodyFrequently asked questions
Why keep three constants that nothing writes?
Because removing them is a schema decision and the defect was that they were shown to users. That is fixed — the filter renders the recorded list. If maintenance is ever built, these are the values it would write.
Can I add a custom movement action?
No. The list is fixed in code, which is a constraint and also the reason it can be enumerated and tested. A configurable action list would make the ten-minute check above impossible to run.
Does a movement require approval?
Approval is one of the nine recorded actions, so where your process requires one it is captured as an event in the same history. Whether a given movement demands one is a matter of how your permissions are granted rather than a fixed rule.
