The Service Pack

1. Read the parent standard first

The specification is the rejected pack build standard, which names the binding layer as the step not to hand-roll and explains why. This paper adds what changes when the pack is a service record rather than a claim or an invoice, and it changes in three places: the identity being bound to, the kinds of evidence, and who is waiting at the end.

2. The twelve checks, in order

The order is not cosmetic. Identity comes first because every later check is meaningless if it is attached to the wrong thing. A missing electrical certificate is checked before defects are coded, because it stops the close outright. The client-facing document is generated from the record rather than assembled alongside it. These are the same twelve checks, in the same order, as the conformance checklist in section 10.

1. Identity before everything. A record cannot be created without resolving to exactly one asset. An unresolvable asset is a finding, not a note on the job.
2. The visit discharges something. Every record names the obligation it satisfies. A visit that discharges nothing cannot be counted as coverage.
3. Result is recorded, never computed. Pass, defect or isolated is entered by the competent person who attended. Nothing in the system derives it from the evidence.
4. Evidence is a property of the class. Required evidence differs by asset class, and readings are stored as numbers in fields rather than photographs of gauges.
5. Baseline absence is reportable. Where baseline data was required and unavailable, the record stores that as a non-conformance rather than leaving the field blank.
6. Electrical work blocks the close. A missing certificate or test sheet stops the job closing. It never raises a reminder and lets the job through.
7. Defects are coded. Defects come from a closed list with a named owner for the next action, so they can be counted and chased. Free text is a description, not a defect.
8. Isolation carries a revisit date. An isolation records who authorised it, why, and the date it must be revisited, and it escalates when that date passes.
9. Unbound is a queue you can see. Work marked done with required evidence missing sits in its own queue with its age on a chart. It is never reported as a pass.
10. Documents are generated from the record. Anything client-facing is derived from the bound record, never assembled from a template on somebody's desktop.
11. Jurisdiction is data. Retention period and who may attest are dated, cited values per state, not constants in the code.
12. The pass test passes. The signature stays with a person. The build assembles and presents the pack; it does not certify, decide compliance, or produce a certificate.

3. Four queues, and unbound is not pass

If you implement one thing from this paper, implement the unbound queue and put its age on a chart. Every business we have looked at believes its number is near zero before it is measured, and the reason is structural rather than cultural: nothing anywhere else in the system has a reason to mention it.

The blocked queue is part of the shape, but none of the twelve checks tests it yet. A build can pass every check and still lose blocked visits, so look for that queue by hand.

4. Different asset classes need different evidence

A single required-evidence list across the whole register is the second common mistake. It is either so short it proves nothing, or so long that technicians photograph things that do not matter and skip the one that does. Required evidence is a property of the obligation class.

5. The exception that needs naming

An asset taken out of service temporarily is a legitimate outcome and it is the one exception most systems handle badly, because it looks like a resolution. It is not. An isolation without a retest date is a defect wearing a different label, and it is the state most likely to still be true a year later with nobody accountable.

Record it as its own result, with who authorised it, why, and the date it must be revisited. If that date passes, it escalates like any other breached obligation and it does not clear itself when the work is eventually done.

6. Who is waiting at the end

The pack exists to be handed to somebody who signs. That person is the reason every check above is worth enforcing, and they are also the reason none of this should be automated past them. A model may check that required fields are present and flag a photograph that does not show what it should. It does not decide that the asset complies, and it does not produce a certificate.

The attestation stays with a person, in every state. In New South Wales only an accredited practitioner may assess each measure and endorse the annual statement; in Queensland the occupier signs the yearly statement; in Victoria the owner prepares the annual report. Whatever the build does, do not automate past that signature. The machine binds evidence and produces it. It never attests.

Read that boundary alongside the industry map, which lists the specific things in this trade that stay with a licensed person.

7. Jurisdiction is data, not a constant

The same physical asset sits under a different annual attestation, a different retention period and a different answer to “who may sign” depending on the building’s address. Queensland runs on an occupier’s statement, New South Wales on an annual fire safety statement that only an accredited practitioner may endorse, Victoria on an annual essential safety measures report prepared by the owner. Retention differs too, and so does how long you have to produce the pack when somebody asks.

A build that hard-codes one retention period is wrong in the other states, quietly, until an audit. Hold these as dated values keyed by jurisdiction, with the source and the date they were checked stored beside them, so a change is one edit rather than a re-read of the whole build.

8. The objects, and the fields that make them bindable

Section 2 says evidence binds to an asset identity before close. That is only enforceable if the identity is a field rather than a description, so here are the objects this standard actually needs. Names are illustrative; the shape is not.

asset:
  id:            string         # stable, and printed on the tag. Not "the one in the kitchen"
  site_id:       string
  class:         portable | system_with_readings | electrical | passive
  obligations:   [obligation_id]

obligation:
  id:            string
  asset_id:      string
  interval:      string         # the servicing cycle this asset is on
  jurisdiction:  QLD | NSW | VIC | ...   # decides retention and who may attest
  next_due:      date

service_record:
  id:            string
  asset_id:      string         # REQUIRED. No asset, no record: that is a finding
  obligation_id: string         # what this visit discharges. Null is not valid
  result:        pass | defect | isolated       # recorded, never computed
  performed_by:  person_id
  competency:    string         # the qualification or accreditation relied on
  baseline_seen: boolean        # false is a recorded non-conformance, not a blank
  performed_at:  timestamp

evidence:
  record_id:     string
  kind:          identity | location | tag | reading | certificate
  value:         number | file_ref            # readings are numbers in fields
  captured_at:   timestamp

defect:
  record_id:     string
  code:          string         # from a closed list. A paragraph is not a defect
  owner:         person_id
  rectified_at:  timestamp | null

isolation:
  record_id:     string
  authorised_by: person_id
  reason:        string
  revisit_by:    date           # an isolation without this is a defect in disguise

queue:              pass | defect | blocked | unbound

The two fields that carry the whole standard are service_record.asset_id and evidence. If a record can exist without them, the unbound queue in section 3 cannot be built, and unbound work stays invisible.

9. Provider: what to stub, and what not to hand-roll

Section 1 points at the parent standard, which names the binding layer as the step not to hand-roll and says plainly that no product covers it. That is still true here. This block exists so an agent does not go looking for one, and does not stand up a second document store beside the one the business already keeps.

provider:
  stub:       local.mock_asset_register
  production: none                       # scoped build, not a product

# There is no product for the binding layer. That is the honest answer and it
# is section 8 of the parent standard. If one ever covers it, this standard
# will name it here.

reads_from:                      # connect what exists. Do not migrate.
  document_store: microsoft_365 | google_drive
  job_system:     whatever they already run
  asset_register: wherever the tags are already recorded

stays_local:
  - the asset identity, and that evidence binds to it before close
  - the twelve checks, in order
  - the four queues, and that unbound is not pass
  - retention and attestation as dated values per jurisdiction
  - the signature, which stays with a person

Fire and electrical work is licensed work. The build routes and records; it does not decide competency and it does not sign.

10. Conformance checklist

A build conforms to this standard when every line is true. Hand it to whoever built yours, including an AI coding agent, and make them answer it.

• ✓1. Identity before everything. A record cannot be created without resolving to exactly one asset. An unresolvable asset is a finding, not a note on the job.
• ✓2. The visit discharges something. Every record names the obligation it satisfies. A visit that discharges nothing cannot be counted as coverage.
• ✓3. Result is recorded, never computed. Pass, defect or isolated is entered by the competent person who attended. Nothing in the system derives it from the evidence.
• ✓4. Evidence is a property of the class. Required evidence differs by asset class, and readings are stored as numbers in fields rather than photographs of gauges.
• ✓5. Baseline absence is reportable. Where baseline data was required and unavailable, the record stores that as a non-conformance rather than leaving the field blank.
• ✓6. Electrical work blocks the close. A missing certificate or test sheet stops the job closing. It never raises a reminder and lets the job through.
• ✓7. Defects are coded. Defects come from a closed list with a named owner for the next action, so they can be counted and chased. Free text is a description, not a defect.
• ✓8. Isolation carries a revisit date. An isolation records who authorised it, why, and the date it must be revisited, and it escalates when that date passes.
• ✓9. Unbound is a queue you can see. Work marked done with required evidence missing sits in its own queue with its age on a chart. It is never reported as a pass.
• ✓10. Documents are generated from the record. Anything client-facing is derived from the bound record, never assembled from a template on somebody's desktop.
• ✓11. Jurisdiction is data. Retention period and who may attest are dated, cited values per state, not constants in the code.
• ✓12. The pass test passes. The signature stays with a person. The build assembles and presents the pack; it does not certify, decide compliance, or produce a certificate.