HPDBN External Optimization
HPDBN supports solving externally defined optimization problems asynchronously and only for non-urgent work. Examples include route assignment, node load balancing, scheduling, connection weights, and quantum or QUBO-formatted problems. Local inference and the application safety layer continue even when an external result never arrives.
Problem lifecycle
sequenceDiagram
participant App as Application
participant PFC as Local PFC
participant Solver as External Solver
participant Verify as Core Validator
App->>PFC: summary input + problem definition
PFC->>PFC: evaluate urgency, deadline, and link
PFC->>Solver: versioned problem envelope
Solver-->>Verify: solution envelope
Verify->>Verify: verify auth, age, generation, hash, constraints
Verify-->>App: verified plan or rejection reason
PFC-->>App: continue local path
Problem definition
The external solver receives a versioned structured envelope rather than an opaque, application-defined string. At minimum it contains:
| Field | Purpose |
|---|---|
problem_id / problem_version |
Identify the problem schema |
node_id / model_version |
Bind the request to a node and model |
input_hash |
Bind the problem to an observation summary |
plan_generation |
Prevent reapplying an older plan |
created_at_us / expires_at_us |
Enforce monotonic-time validity |
| Objective and constraints | Define the meaning and valid region of a solution |
| Allowed variables and size limits | Prevent unintended expansion and resource exhaustion |
| Authentication metadata | Verify origin and integrity |
Raw images, raw point clouds, private keys, and internal Safety Barrier state are excluded. Required information is reduced to the minimum feature or aggregate representation.
Solution verification and application
Receiving a solution is not permission to apply it. Core or the application validator checks:
- The sender is authenticated and the message integrity is valid.
problem_version,model_version, andnode_idmatch the active contract.input_hashmatches the current observation summary.plan_generationis newer than the active generation.- Monotonic timestamps are current and are not in the future.
- Variable types, ranges, sizes, and constraints are valid.
- The objective value and verification result meet the configured threshold.
A solution is rejected and its reason code is recorded in the audit log when any check fails. Even a verified plan remains subject to rejection by the Safety Barrier.
Communication loss, latency, and solver failure
- Do not submit new external jobs when communication is lost or RTT exceeds its limit.
- Never apply an expired job result.
- Do not silently replace a solver failure, timeout, or partial result with a local plan.
- The application may explicitly use a time-limited cache where appropriate.
- Define the no-result behavior through a local CPU/SNN path or the Safety Barrier.
QUBO, quantum, ground-GPU, and cloud optimization are not synchronization points for urgent control. Measure worst-case solver time and network latency for every target device and network.
SDK and existing plugins
An existing DevicePlugin is not itself an external optimization service. Reuse device execution through DevicePluginRuntimeAdapter; manage problem definition, submission, verification, and application of external plans at a separate application boundary.
See the HPDBN SDK integration guide and EvoSpikeNet-Core/examples/sdk/hpdbn_existing_plugin_bridge.py.
Responsibility boundary
The Core standard defines the contract boundary for deadlines, generations, hashes, authentication, and constraint validation. The application owns objective validity, solver quality, vehicle- or robot-specific control, safety certification, and secret management.