Decision D 003

D-003 Build a complete everyday-to-disaster service demonstration

Start here · Questions · Progress · People decide

Review scope: The first software and service demonstration. State: ready for people to review

Choose the first connected jobs to demonstrate, so we can test the kiosk, information, people, messages and Aura learning as a working whole.

The choices

Choice	What it brings	What to plan for
Public information and calendar first	Demonstrate reviewed notices, events, corrections and saved information.	Request handovers and personal learning join in a later demonstration.
Connected service demonstration	Demonstrate public information, bounded assistance, readiness records and Aura learning across several simulated locations.	Use clear sample records and test the different receiving, approval and failure states.
Prepare a field pilot alongside the software	Develop a real host and hardware trial while the service takes shape.	Coordinate people, equipment, site arrangements and resources earlier.

Recommended next step

Start with a connected service demonstration using sample records at three logical locations and a portable unit. Practise everyday work, lost connections and recovery, then prepare the measured hardware and field trials.

What this decision moves forward

• Demonstrate three everyday tasks: find checked events and transport information; find a local notice or service; use guided assistance or learning.
• Demonstrate disaster information, service/resource readiness and request handover with honest source and receipt states.
• Prepare a two-to-three-day practical service exercise with disconnected operation, staff handovers and recovery. Digital-twin simulations can cover any chosen time span, recorded separately from practical test duration and computer runtime.

Later milestones with their own reviews

• People responsible for real information and requests agree their service arrangements before public use.
• Actual endurance, weather performance and pilot-site readiness are established through their own measurements and reviews.

What people review

• Can residents and visitors complete the everyday jobs without a personal account?
• Does a changed or unresolved warning keep its source, time and meaning when a connection fails?
• Can people see whether a request is saved, received, assigned or completed?
• Does Aura offer relevant learning with a source, prerequisites and a human handover?
• Can another steward restore the service and continue outstanding work?
• Does the proposal identify overlapping professional responsibilities, applicable practice and legal sources, and the comparison of differences, improvements and deficiencies?

Questions: OPS-01, DAT-01, SW-01, AUR-01, TWIN-01, TEST-01

Reviewers: Luke, as project initiator, reviewing planning choices within his responsibilities alongside the relevant professional review process

Open the GitHub review conversation.

Record the human decision

The fingerprint below identifies this exact proposal and its supporting files. A changed proposal gets a fresh fingerprint and review. A person may approve, request changes or reject it. How reviews work.

272bb422f389c943449362edf52b9296e1c795540126c4dba9a2529ccfb84891

Evidence fingerprint: 4c613aeac3308dedbbdc4f129a7da24873dbaa8df0fdbd3a6a9d98829314a62f.

For approval, the named person posts this line in the linked GitHub issue after reading the proposal:

HITL APPROVE D-003 272bb422f389c943449362edf52b9296e1c795540126c4dba9a2529ccfb84891 scope=prototype_service
Conditions: none

Use CHANGE or REJECT in place of APPROVE to record that outcome. For conditional agreement, state the conditions in the Conditions field; that record awaits a fresh decision when they are met. Keep an approval comment to the displayed fields and discuss reasons in a separate comment. An optional Valid-until: field takes an ISO date/time with its timezone. AI assistants prepare the proposal and carry out authorised follow-up; the human decision belongs to the named person.