Fleet Governance

Know exactly what’s running on every node. Prove it cryptographically.

Hexarch separates authority (what you want running) from execution (what’s actually running). The Fleet Governance dashboard shows both—and provides cryptographic proof that they match.

Authority vs. Execution

Every cluster tracks two states:

Authority (Desired State)

• The configuration snapshot the control plane intends to deploy
• Includes a verification hash (cryptographic proof of content)
• Managed centrally, versioned, audited

Execution (Applied State)

• What’s actually running on each gateway node
• Verified by comparing node state against the authority hash
• Updated via hot-swap—no restarts required

When authority and execution match, the fleet is cohesive. When they don’t, you have drift.

Fleet cohesion

Cohesion is the percentage of nodes running the desired configuration:

The dashboard shows cohesion as a visual bar with real-time updates.

Node-level visibility

For each gateway node, you can see:

• Process Health: Healthy, Degraded, or Offline (with heartbeat status)
• Config Status: IN SYNC or DIVERGENT
• Drift Root Cause: Specific sync errors (e.g., “JVM_RELOAD_FAILED: Incompatible Filter Signature”)
• Metrics: CPU%, Memory%, Transactions/sec

This isn’t “green/red” monitoring. When something’s wrong, you see why—not just that it’s broken.

Cryptographic verification

Every configuration snapshot includes a verification hash. When a node reports its applied state, Hexarch compares:

1. The node’s reported snapshot hash
2. The authority’s expected hash

If they match, the node’s configuration is verified. If they don’t, the node is flagged as divergent.

This is how you prove—not assume—that your fleet is running the intended policy.

Reconciliation

When nodes drift, you have options:

Automatic Reconciliation

• Enabled per-cluster
• Nodes automatically sync to authority on detection
• Audit trail records the reconciliation

Manual Force Sync

• Per-node or cluster-wide
• Requires administrative justification (recorded in audit)
• Used for emergency recovery or controlled rollouts

Global Fleet Overwrite

• Cluster-wide reconciliation with strict role access
• For disaster recovery scenarios
• Full audit trail with justification

Administrative overrides

Force sync actions require:

1. Target identification — which cluster or node
2. Justification — why the override is necessary
3. Audit recording — immutable log of the action

Example justifications:

• “Emergency disaster recovery”
• “Node re-provisioning after hardware failure”
• “Rollback due to failed deployment”

These aren’t optional. The audit trail is how you explain what happened during an incident.

Cluster health states

Each cluster also shows:

• Environment (Production, Staging, Development)
• Owner team (for accountability)
• Auto-reconcile policy (enabled/disabled)

JVM-specific monitoring

For Java Gateway deployments, Hexarch tracks:

• JVM heap usage (percentage and trend)
• Hot-swap errors during policy reload
• Agent version compatibility
• Memory pressure during reconciliation

When a reload fails, you see the specific cause—not just “sync failed.”

Why this matters

Without Fleet Governance:

• “We deployed the config” means hoping it propagated
• Drift goes unnoticed until something breaks
• Incident response starts with “what’s actually running?”

With Fleet Governance:

• Deployment is verified, not assumed
• Drift is visible immediately
• You can prove exactly what was running at any point in time

Next steps

• Configuration Lifecycle — how artifacts become deployed snapshots
• Cryptographic Audit Chains — how verification works
• API Reference — endpoints for fleet management