Build a silo outload application

A driver presents a credential. The site authorises a maximum quantity in tonnes against a silo, the bay / chute runs a short irreversible outload, and the final load ticket settles only what the meter reported. If connectivity disappears halfway through, the event waits and reconciles when the site comes back online.

That is the project you will assemble in this workshop. It pairs naturally with silo level monitoring (SiloSentry-style): watch the level, and authorise what leaves the silo.

The finished customer product starts with something simple and useful: a clear list of active outload tags.

Behind that table, activity shows current offline sync, bay commands, released remainders, and a delayed completion waiting for reconciliation.

What this tutorial actually does

Use a simulator or a non-loading test bay. Prelude runs the real records, process, internal quantity reservation, command and event transport, offline dataset, and reconciliation path. The proof harness simulates the outload bay and site gateway. You must supply and qualify the chute / auger controller, meter, safety interlocks, credential policy, and any ERP or weighbridge integration. Nothing in this walkthrough certifies physical grain movement. The physical chute is still simulated in the proof harness.

See how the pieces connect

By the end you will have:

• Outload Bay and Site Gateway Device Classes
• bay and gateway bindings
• a customer-managed silo record plus outload tags and secret driver PIN records
• separate site_outload_tags and site_driver_codes offline datasets
• load_ticket history for settled and failed requests (quantity in tonnes)
• an authorise_outload command
• a durable request_outload process
• walk-away, partial-settlement, and reconnect paths

What you need

• Product Applications beta access on Standard+
• a test customer and Customer Portal
• an Outload Bay Device Class and a representative non-loading test bay
• a Site Gateway Device Class and representative gateway
• a safe device-side handler for authorisation and event reporting
• an internal test allotment account (tonnes), not a real weighbridge settlement

Never test workflow changes against an enabled production chute.

1. Give the bay and gateway separate jobs

Create or select these Device Classes:

Device Class	Binding	Job in this application
Outload Bay	bay	Enforce local interlocks, apply a bounded authorisation, meter the outload, and emit events
Site Gateway	gateway	Keep the approved credential dataset available to the local site runtime

A Device Class is the reusable hardware contract. The cloud can request an authorisation, but the bay must remain safe when cloud state is stale, duplicated, delayed, or unavailable.

Keep the bay and gateway as separate hardware products, then give each one a role in the application.

The application sends only the credential fields the site runtime needs.

2. Create the application

1. Open Developer > Product Applications.
2. Create Silo outload with key grain_outload.
3. In Build > Hardware, bind Outload Bay as bay.
4. Bind Site Gateway as gateway.
5. Confirm that test devices from each class are eligible for the right role.

Bindings are stable application names. Avoid using a particular device name, such as Bay-1, as a definition key.

Check bay and gateway placement in the intended customer before testing records or operations.

3. Create silos, outload tags, and driver codes

In Build > Models, add configuration and operational models:

Model	Useful fields	Purpose
silo	name, capacity_tonnes, units	The bin you load against (ties to SiloSentry-style monitoring)
outload_tag	tag_uid, label, status	Identifies a vehicle or physical RFID tag
driver_code	label, secret pin, pin_hint, status	Lets a driver authenticate without exposing the PIN again
load_ticket	silo, bay_device, quantity_tonnes, identity, status	Settled / walk-away history

The PIN field is write-only. After you save it, reads return only that a value is set; the portal never receives the plaintext back. A separate hint such as ••68 can help an operator identify the code without weakening that boundary.

A production model may also need vehicle references, validity windows, limits, and an audit identity. Do not put unnecessary personal information into either offline projection.

Configuration, secret authentication, and load ticket history stay separate instead of becoming one overloaded credential table.

The proof stores a real secret field, but the screenshot can only show that the PIN is set.

4. Send credentials to the site

An offline dataset is a versioned package of application records that a device can keep using without a live cloud connection.

Add two small datasets:

Key	Projection
site_outload_tags	outload_tag.tag_uid, outload_tag.label, outload_tag.status
site_driver_codes	driver_code.label, hashed driver_code.pin, driver_code.pin_hint, driver_code.status

Generate a base dataset after publishing, then use deltas for bounded changes. The Prelude Agent verifies, stages, and atomically activates each generation. It keeps the last-known-good version if verification or activation fails.

Desired generation tells you what the cloud wants. Applied generation tells you what the gateway actually activated. Wait for the Customer Portal sync chip to show current.

The driver-code projection receives a one-way hash suitable for local verification, never the original PIN. Treat that hash as sensitive operational data even though it is not plaintext.

The running draft keeps tag lookup and secret-backed code verification in separate versioned datasets.

Preview the generated JSON from real customer records before sending it to a gateway.

5. Add the bay command

Create Authorise outload with key authorise_outload, binding bay, and a 30-second timeout.

The bay-side handler should:

• validate correlation and authorisation IDs
• reject quantities outside local policy
• apply the maximum only once
• report a terminal command result
• emit outload.started and outload.completed with the same identity
• keep completion events durably until the cloud acknowledges them

Command success is not the quantity loaded. Settlement comes from the measured completion event (quantity_tonnes).

6. Build the request process

Create Request outload with key request_outload.

A process is a durable workflow that can wait for a command, event, or timer. This one has three useful endings:

The proof uses a short 10-second completion timeout so you can see reconciliation without waiting. Choose production timing from real bay and network tests.

The internal allotment demonstrates reserve, partial commit, and release semantics. It is not your weighbridge or ERP ledger.

7. Choose what customers can do

In Access, expose only deliberate actions:

• manage credentials and silos for authorised administrators
• request outload through a reviewed operation or external API
• view load ticket state and customer-safe activity

Keep raw bay commands, authority controls, reconciliation internals, and OEM diagnostics out of ordinary portal roles.

If an ERP or weighbridge is authoritative, connect it with its own idempotency and reconciliation design.

8. Publish and run the online path

1. Validate and publish version 1.
2. Attach it to the staging portal and provision Prairie Outload.
3. Create a silo plus active and suspended test credentials.
4. Preview and generate site_outload_tags and site_driver_codes.
5. Let the test gateway apply both generations and report them.
6. Create the bounded internal tonne allotment account.
7. Start request_outload with unique authorisation and correlation IDs.
8. Report the bay command as succeeded.
9. Emit outload.started.
10. Emit outload.completed with a quantity below the reserved maximum.
11. Confirm that only the measured tonnes are committed.
12. Confirm that the remainder is released.

The request process appends a load_ticket row, so the outcome survives after the command and process views have moved on:

Load ticket history keeps the measured quantities and safe identity hints visible after each request completes.

Repeat without outload.started. The full reservation should be released with walk_away_timeout.

A customer can open the same outload tag that was projected to the site gateway.

9. Pull the plug, then reconcile

Issue a bounded authority grant tied to the current credential generation. Replace it once and confirm the old grant is no longer active.

While the test gateway is disconnected:

1. consume only within the local grant and policy
2. create a globally unique durable event ID
3. preserve the event across restart
4. upload it after reconnection
5. retry that same event deliberately

The server should apply the event once, commit the measured quantity, release the remainder, and acknowledge the event before local deletion. Also test hard expiry and storage exhaustion.

This proves delivery, acknowledgement, deduplication, and reconciliation through the real Prelude boundary. It still does not prove that grain moved or a physical interlock operated.

Before you put it near a real chute

• Keep bay safety independent of cloud availability.
• Give authorisations and completion events durable unique identities.
• Release the full reservation after a walk-away.
• Commit only the measured tonnes after a partial outload.
• Reconcile a missing completion instead of guessing.
• Make offline grants bounded, replaceable, generation-linked, and expiring.
• Preserve unacknowledged events across restart.
• Remove suspended credentials from the next applied generation.
• Test customer roles and cross-customer isolation.
• Document metrology, weighbridge, and site safety responsibilities.

Related

• Product Applications
• Device data and control contract
• Customer Portal
• Production limits and service behaviour