Cloud records systems fail in a specific way in rural and remote communities. The connection drops, and the filing cabinet is somewhere else. Staff go back to a shared drive, or to paper, and the record you were building disappears for a week.

So we put the system in the building. An EdgePod appliance sits on the customer's own network, and everything the system needs runs on it: storage, the database, search indexing, text recognition on scanned material, thumbnail and preview generation, document conversion, model inference, and the rules engine. There is no step that has to leave the premises to complete.

The request path is deliberately short. A user's action touches the web server, the application runtime, the database and the file store, and nothing else. Everything expensive is pushed off that path and handled as background work through a job queue: indexing, previews, text recognition, conversion, rule evaluation and notifications. That is why the interface stays responsive while a hundred scanned pages are being processed behind it.

Conversion is a preservation decision, not a convenience. Material entering as a final record is converted to a stable format on write, because a record held in a proprietary editing format is only as readable as one vendor's future product decisions. Authored working documents stay editable. The policy is set per entity, not by us.

When the line goes down, work continues. When the line comes back, nothing has to be reconciled, because nothing was waiting somewhere else. That is the whole argument for local execution, and it is the reason the hardware is a line item rather than something we hide.