Project Bantay BayanCommunity resilience infrastructure

Auxilus Mos · Utility and public service coordination

PBB Utility / Vena

Inbound Hotline incident context, utility assets and teams, local missions, and responder acknowledgement for operators.

Integrated · Production hardening Baseline node service
Primary placement
Utility operations node
Primary users
Utility operators, Utility command staff, Utility administrators, Assigned responders

What it is

A practical part of one local platform

PBB Utility / Vena is a Laravel utility-operations module. Relay delivers validated Hotline incident snapshots targeted to utility.vena; Vena retains the inbound envelope, quarantines invalid or stale data, normalizes the current incident, and places it beside utility assets, teams, maps, and local missions.

The confirmed V1 path is inbound-only. Operator mission work and web responder acknowledgement are local; outbound utility lifecycle updates, PBB Realtime integration, and an offline mobile responder helper are not confirmed.

Problem it solves

The operational gap

Utility teams need validated emergency context in their own local operating surface without exposing direct media paths or assuming a two-way lifecycle that has not yet been implemented.

Core workflow

How Vena supports local work

  1. Receive a validated handoff

    Relay posts a Hotline incident snapshot with the required type, target, version, identity, and metadata-only media references.

  2. Quarantine or normalize

    Vena retains the raw envelope, rejects invalid or stale inputs, and updates the normalized local incident when valid.

  3. Coordinate utility work

    Operators review incident context beside assets and teams, then create and manage a local mission.

  4. Acknowledge assignment

    A responder can review and accept an assigned mission through the current web surface.

Who uses it

Designed around local service roles

  • Utility operators
  • Utility command staff
  • Utility administrators
  • Assigned responders

Offline-first behavior

What continues locally—and what does not

Works on the local node

  • Accepted incidents, assets, teams, missions, responder views, and activity history remain in the local Vena database.
  • The operator and responder web surfaces can continue on the LAN after the incident has been delivered.

Required local services

  • Vena requires its Laravel application, MySQL database, and role-based local session.
  • Prepared local map display depends on configured MapServer tile URLs and coverage.

When a route returns

  • Relay can deliver new or newer Hotline incident snapshots when a route to the utility node is available.
  • No confirmed outbound status synchronization occurs after local mission handling.

Connectivity-dependent

  • Cross-node incident intake depends on Relay delivery to the configured Vena handler.
  • Map cache misses may depend on upstream providers when local coverage was not prepared.

Not currently synchronized

  • No outbound utility mission, responder, or lifecycle update contract is confirmed.
  • No native or PWA mobile offline queue and no Realtime responder tracking are confirmed.

Deployment placement

Where it fits

Special deployment

Utility operations node

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

Practical questions

Frequently asked questions

How does Vena receive emergency incidents?

Relay securely sends approved Hotline incident updates to Vena for utility teams to handle.

What happens to invalid or stale messages?

Vena sets aside messages that are incorrect, meant for another system, too old, or otherwise unsafe. This prevents them from replacing valid information.

Does Vena send mission status back to Hotline?

Not in the confirmed V1 design. After Hotline hands an incident to Vena, mission work and status information remain local to Vena.

Can utility operators continue without internet?

Yes. After an incident reaches Vena, operators can continue using local information about assets, teams, missions, and responders while Vena is running on the local PBB network.

Is the responder view an offline mobile helper app?

No. The current responder view is a web page served by the local node. A separate mobile workflow designed to work offline is still planned.

Does Vena receive direct incident media URLs?

No. Vena receives only basic information describing related media, not direct file locations or web links. Messages containing those direct locations are set aside.

Status and readiness

Integrated

Inbound Relay intake, quarantine and stale handling, normalized incidents, assets, teams, maps, missions, and responder acceptance are implemented.

Remaining hardening work

  • Define whether utility mission and lifecycle updates remain local or gain an outbound contract.
  • Approve raw payload retention, audit, purge, and encrypted backup policy.
  • Keep the planned mobile offline helper separate until its contracts are implemented.

Connected platform

Emergency and operations PBB Hotline / Vox Local emergency intake, incident handling, command reporting, and support coordination.
Emergency and operations PBB Support System / Imperium Consolidates SITREPs and manages support-request lifecycles at designated support nodes.
Emergency and operations PBB Salus / Salus Local evacuation-center registration, occupancy, and relief-receipt operations in active development.

Local-node foundation

Local-node infrastructure PBB Relay Selective store-and-forward messaging between nodes. 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 Vena in a local PBB deployment

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

Request a briefing