Project Bantay BayanCommunity resilience infrastructure

Auxilus Mos · Emergency and operations

PBB Support System / Imperium

A designated support-node workbench for consolidating SITREPs and managing inter-node support requests.

Integrated · Production hardening Baseline node service
Primary placement
Designated support node; Local command node
Primary users
Support operators, Receiving agencies, Emergency coordinators, Support-node administrators

What it is

A practical part of one local platform

PBB Support System / Imperium receives Relay-delivered situation reports and support requests at a designated support node. It stages the latest valid report from each source, prepares a consolidated current picture, and gives support operators a controlled request lifecycle.

Imperium also receives Relay source-heartbeat operational webhooks and can publish accepted snapshots through PBB Realtime. Its placement, users, credentials, retention rules, and receiving-agency authority remain deployment-specific.

Problem it solves

The operational gap

Local emergency nodes need a structured way to request outside help and give receiving agencies a consolidated, current view without copying every editable incident record across the network.

Core workflow

How Imperium supports local work

  1. Receive selected reports

    Relay delivers validated SITREPs, support requests, and operational source-heartbeat events to the designated node.

  2. Consolidate current context

    Imperium stages the latest valid SITREP per source and builds a current support-level picture.

  3. Coordinate support

    Operators review, accept, reject, assign, track, and fulfill support requests through a local lifecycle.

  4. Send selected updates

    Consolidated SITREPs and request lifecycle events enter Relay-backed delivery when the route is reachable.

Who uses it

Designed around local service roles

  • Support operators
  • Receiving agencies
  • Emergency coordinators
  • Support-node administrators

Offline-first behavior

What continues locally—and what does not

Works on the local node

  • Staged SITREPs, consolidation, request review, operator actions, and local history remain available from the support database.
  • Prepared map context can remain available from the local MapServer cache.

Required local services

  • The Laravel application, MySQL, queue worker, and scheduler support the confirmed workflows.
  • Relay is required for new cross-node intake and outbound lifecycle delivery; MapServer and Realtime support their configured views.

When a route returns

  • Relay can deliver new source SITREPs and Hotline support requests.
  • Imperium can submit consolidated SITREPs and supported lifecycle updates through Relay.

Connectivity-dependent

  • Cross-node delivery depends on a reachable Relay route and configured topology.
  • Remote evidence access requires a separately configured and authorized Hotline media endpoint.

Not currently synchronized

  • Imperium does not create universal database replication between nodes.
  • Editable Hotline incidents are not copied into a shared mutable incident database.

Deployment placement

Where it fits

Special deployment

Designated support node; Local command node

Hardware, connectivity, power, training, travel, and field logistics remain deployment-specific.

Practical questions

Frequently asked questions

Where should Imperium be deployed?

Imperium should run on an approved support or command node. The deployment owner decides whether that node belongs to a city, municipality, province, agency, or PBB headquarters.

Does it copy every Hotline incident?

No. Imperium receives selected situation reports and support requests, not full editable copies of every Hotline incident.

What remains available when upstream connectivity is lost?

Reports already received, the combined situation view, local support requests, and local history remain available while the node services are running.

How are source heartbeats received?

Relay sends a separate status update that tells Imperium whether a reporting source is still active. These health updates are kept separate from ordinary reports and requests.

Will the support map work offline?

Only map areas and boundaries prepared in advance will work reliably offline. Looking outside those prepared areas may require an online map source.

Is Imperium ready for unrestricted agency access?

No. Before agencies share it, the deployment owner must strengthen and approve user roles, sign-in credentials, who may receive requests, how long records are kept, and the operating procedures.

Status and readiness

Integrated

SITREP intake and consolidation, support-request handling, Relay delivery, source-heartbeat webhooks, Realtime publishing, and map context are implemented.

Remaining hardening work

  • Confirm operational placement and receiving-agency authority.
  • Harden role enforcement and remove development credentials.
  • Publish token ownership, retention, and multi-node operating runbooks.

Connected platform

Emergency and operations PBB Hotline / Vox Local emergency intake, incident handling, command reporting, and support coordination.
Emergency and operations PBB Salus / Salus Local evacuation-center registration, occupancy, and relief-receipt operations in active development.
Utility and public service coordination PBB Utility / Vena Inbound incident context and local mission coordination for designated utility operators.

Local-node foundation

Local-node infrastructure PBB Relay Selective store-and-forward messaging between nodes. Local-node infrastructure PBB Realtime One shared local WebSocket gateway per node. Local-node infrastructure PBB MapServer Prepared local map tiles and boundaries. Local-node infrastructure PBB Account Local canonical identity and OAuth-style SSO.

Briefing and pilot discussion

Discuss Imperium in a local PBB deployment

Explore how a local-node deployment could support practical service continuity in your community.

Request a briefing