The Cited Answer Build Standard

1. What this standard covers

Any assistant that answers questions about a body of rules where being wrong has a consequence somebody else carries. Australian Standards and their state variations, the building codes, work health and safety regulations, the residential tenancy acts, an award, an insurer’s policy wording, or your own contracts and scopes of work. If the answer could end up quoted back to you by somebody who relied on it, this standard applies.

It does not cover assistants that draft, summarise or rewrite your own material. Those have their own failure modes and none of them are this one. The distinguishing feature here is that the truth lives outside your business, it is versioned, and it moves without telling you.

The failure this prevents is specific and it is not hallucination in general. It is the answer that was correct eighteen months ago, delivered today with the same confidence, because the model learned the rule rather than reading it.

2. The objects, and what is in them

Five objects. The source card is the one that does the work, and it is the one most implementations leave out because retrieval appears to function without it.

Instrument
  - id, title, issuing body, jurisdiction
  - edition, effective_from, effective_to (null while live)
  - file or url, retrieved_at

Clause
  - id, instrument_id, clause_reference, text
  - supersedes (clause id, nullable)

SourceCard
  - id, clause_id, instrument_id
  - edition, jurisdiction, effective_from
  - accepted_by (person), accepted_on
  - retired_on (nullable)
  - status (live | change_pending | retired)

Answer
  - id, question, asked_on, asked_about_date, jurisdiction
  - audience (internal | public)
  - body, source_card_ids (one or more, or none)
  - queue (answered | declined | conflict | change_pending)

ChangeDelta
  - id, instrument_id, detected_on, summary
  - status (pending | accepted | rejected)
  - decided_by (person), decided_on
  - affected_answer_ids

An Answer with an empty source_card_ids and a queue of answered is the defect this whole standard exists to make impossible. It should not be representable, which is why the queue is on the object rather than inferred at render time.

3. The checks, in order

The order matters. Jurisdiction and date come first because they change what counts as a live clause, and retrieving before you know them is how a Queensland answer reaches a Victorian site.

1. Identify the jurisdiction and the date the question is being asked about, before retrieving anything. The same question has different answers in two states and in two editions.
2. Retrieve clauses, not documents. A page reference the reader has to search is not a citation.
3. Check every retrieved clause is live on the asked-about date. A superseded clause is not an answer: answer from its accepted live replacement, or, if the change has not been accepted, the question goes to change pending.
4. Compose the answer only from retrieved clauses. Nothing from the model's own memory of the standard reaches the reader.
5. Attach a source card to the answer: instrument, clause, edition, jurisdiction, effective date, and the link or file it came from.
6. If no clause covers it, decline and hand to a named person. Do not answer the nearest question you can source.
7. Apply the audience policy. An internal answer may be specific; a public one never issues, implies or forecloses a certificate.
8. Store the answer with its card. When the instrument later changes, you can find every answer that relied on it.

4. The four queues

Every answer lands in exactly one of these. Three of them are not answers, and a build that only implements the first one has not implemented this standard.

Declining is the output most teams try to engineer away, and it is the one that earns the assistant its place. An assistant that declines twice a day and is right the rest of the time gets used. An assistant that always answers gets checked, and an assistant that gets checked every time is slower than the folder it replaced.

5. The change feed, and who accepts it

Rules move. A new edition lands, a state issues a variation, a regulator publishes a clarification. The assistant does not get to notice this on its own, and it does not get to decide what the change means.

Run a scheduled check against every instrument you hold. When one moves, write a ChangeDelta in pending, mark every source card drawn from that instrument as change pending, and move the answers that relied on them into the change pending queue. Until a named person accepts the delta, those questions are declined rather than answered from a card nobody has re-read.

Acceptance is a person reading the delta and saying what it does to your cards. It is recorded with their name and the date. That record is the thing you produce when somebody asks why an answer given in March differs from the one given in June, and it is the entire reason the ChangeDelta object exists rather than a flag.

6. Internal and public are different policies

The same clause, retrieved the same way, is not the same answer to your own qualified staff and to a member of the public on your website. Hold the difference as a policy on the audience field, not as an instruction in a prompt.

Internal answers may be specific and may name what to do next. Public answers describe what a standard requires and stop. They do not state that a particular installation complies, do not say a certificate would issue, and do not tell somebody how to make safe a thing that is currently unsafe. That is not caution for its own sake. Certification is a person’s signature carrying their licence, and an assistant that forecloses it has taken a decision that was never yours to automate.

7. What stays with a person

• ✓Accepting a change to an instrument, and deciding what it does to existing cards.
• ✓Resolving a source conflict between two live instruments.
• ✓Every certificate, sign-off, statement of compliance and anything that carries a licence number.
• ✓Any answer where the consequence of being wrong is somebody's safety rather than somebody's afternoon.
• ✓Deciding that a question is outside the body of rules you hold, and saying so to the person who asked.

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

Retrieval over a clause library is an ordinary build and you should do it yourself. The part worth naming is that the gate is not a component you can buy.

stub in development
  - a folder of instrument files and a clause table
  - keyword search is enough to build against
  - a hard-coded reviewer as the accepting person

production: none   # no hosted step, build it on your own systems
  - retrieval: your own index over the clause library. Ordinary build.
  - model: whichever you already pay for. It composes, it does not recall.
  - the certifier gate: a named person. There is no product for this
    and you should be suspicious of anyone selling one.

do not skip
  - the source card and the change feed. Not because they are
    difficult, but because they are the two parts that look
    optional while the system appears to work.

There is no product for this standard. A vendor selling a compliance chatbot is selling the retrieval, which is the easy half, and is usually silent about who accepts a rule change. Ask them that question first.

9. Conformance checklist

Hold a DIY build or a vendor to this. If a box is empty, it is not in production.

• ✓1. Every production answer carries a source card. An answer with no card is in the declined queue, not the answered queue.
• ✓2. Cards name an edition, a jurisdiction and an effective date. Not just a document title or a page number.
• ✓3. Superseded clauses cannot produce a live answer. Retiring a clause changes or stops the answers drawn from it.
• ✓4. Instrument changes are accepted before production. A change to an instrument is accepted by a named person before it reaches production. The acceptance is stored with their name and the date.
• ✓5. Declining is an implemented output. Not an error state, and not a fallback paragraph, with a route to a person.
• ✓6. Public and internal answers run different policies. The policy is a field on the answer, not a line in a prompt.
• ✓7. Answers are stored with their cards. You can list every answer that relied on an instrument that just moved.
• ✓8. Nothing issues, implies or forecloses a certificate. The signature stays with the licensed person.
• ✓9. It survives the builder. Someone other than the builder can explain what it does, and it runs on an account the business owns.
• ✓10. The pass test passes. Move one instrument and ask the same question again. The answer changes or declines, and every prior answer that relied on it can be listed.