Centralized coordination requires explicit limits.
The managed surface connects deployment state, runtime supervision, service health, gateway routing for configured routes, policy, incidents, status, audit records, and operator actions. A failure or unauthorized change at this layer can cause downtime, confusion, or loss of evidence.
The trust model must therefore describe offline hosts, unhealthy agents, failed package verification, crash loops, operator actions, access changes, blocked traffic, audit needs, and hosted-plane unavailability. Running, healthy, reachable, and current remain distinct states.
The product claim should be evaluated through current components and records, not company identity. The relevant evidence includes customer approval of new runtime hashes, signed communication, verified packages, bounded restart behavior, action receipts, export paths, and documented customer responsibilities.
The authority spans several operational functions.
The claim touches deployment, supervision, telemetry, policy, recovery, status, service ownership, and operational evidence. It should be evaluated across those authority boundaries.
Centralization can concentrate failure and access risk.
Customers should assess tenant isolation, operator permissions, signing-key handling, hosted-plane dependence, local continuity, removal paths, and bounded recovery.
Trust depends on current, inspectable evidence.
Runtime inspection, repeatable tests, visible failure behavior, action receipts, and audit exports support specific claims for specific versions and environments.
Evaluate the system, contract, and operator workflow.
Architecture explains expected behavior. Runtime records and tests show what happened in a particular environment. Signed agreements define commitments. These sources should be kept distinct when evaluating the platform.
When a customer identifies a defect or unclear boundary, the appropriate response is to reproduce it, correct the implementation or documentation, and record the result. Feedback is part of normal product operation, not evidence by itself.
The current product model includes launcher supervision, agent runtime behavior, package verification, service orchestration, policy pipelines, runtime logs, request evidence, incident coordination, public status, service catalog, audit export, support workflow, and operator controls. Availability and scope may vary by configuration and agreement.
These functions are connected because deployments affect health and incidents; incidents may affect status; policy affects managed traffic; traffic produces evidence; and recovery changes runtime state. Coordination is the product hypothesis. Customers should measure whether it improves their own operating workflow.
The launcher and agent make the operating model inspectable.
The launcher coordinates host enrollment, desired-state synchronization, and agent lifecycle on customer infrastructure. The agent verifies approved workload packages, starts configured services, monitors health, applies bounded restart behavior, and reports operational evidence. These customer-side responsibilities can be inspected without publishing the hosted control plane's proprietary implementation.
Together, the components provide signed machine communication, verified package delivery, host assignment, crash-loop protection, cached recovery paths, manifest validation, multi-service supervision, gateway routing, health checks, and runtime evidence. The architecture explains those responsibilities; operators should validate the resulting behavior in their own environment.
The launcher reconciles desired state with the host.
The launcher identifies its assigned host, receives the workload assignments for that host, acknowledges pending actions, reports runtime status, and maintains the host's connection to the management plane.
Signed requests protect machine communication.
Machine calls include X-Infraveil-Timestamp and X-Infraveil-Signature. The server hashes the body, canonicalizes the request, checks timestamp skew, and compares the expected HMAC signature. The platform does not treat bearer tokens alone as the whole trust model.
New runtime hashes require customer approval.
Manual, allowlist, and auto modes determine how the customer key signs a new runtime hash. Delivery uses AES-GCM and includes X-Payload-Hash plus X-Payload-Signature so the runtime can verify the approved package it received.
The agent supervises configured services.
The agent reads the service manifest, prepares persistent paths and environment settings, runs configured setup steps, starts services, watches process health, exposes gateway routes, and enforces restart budgets.
Cached packages support bounded local continuity.
The launcher can use a cached agent package, and the agent can bootstrap from a cached workload while control-plane sync initializes. This can delay disruption during connectivity or fetch failure; it does not guarantee health, reachability, or current state.
Restart behavior is bounded by design.
The launcher records crash windows and can suspend an agent that enters a crash loop. The agent tracks service restart windows and stops restarting a service once its configured restart budget is exceeded.
Customer-side components expose launcher identity, agent identity, signed sync, encrypted delivery in defined paths, package verification, manifest orchestration, runtime state, cache fallback, restart budgets, action receipts, telemetry, and audit-facing state. Source inspection explains the mechanism; it does not replace observed validation.
Review the operational details.
The review should cover retries, cached packages, signing paths, operator permissions, tenant boundaries, logs, audit trails, failure modes, support state, billing access, and the relationship among the hosted plane, launcher, agent, gateway, dashboard, and customer.
Test the supported path in the intended environment.
Use the signed one-file Trust Console and infraveil.json, inspect the installed components, exercise approvals and failure paths, export available audit evidence, and record observed results. Do not assume public source matches the deployed runtime without verification.
Controls and documentation must change with the product.
Launcher state, agent supervision, package trust, policy execution, runtime evidence, incidents, status, auditability, and operator workflow share dependencies. A change in one area may invalidate assumptions elsewhere.
Customer reports about permissions, exports, failure states, or workflows should lead to reproducible tests and documented changes when warranted. Published claims should be revised when implementation or evidence changes.
Customers should ask about tenant boundaries, signing keys, audit trails, degradation, export paths, support, permissions, billing access, self-hosting, data residency, compliance, and lock-in. Capabilities that are planned or contract-specific should be labeled accordingly.
The question is how customers coordinate responsibilities that cross tools.
Observability, incident response, status, security, uptime, CI/CD, runtime supervision, cloud monitoring, analytics, and developer portals address different operating functions. Customers should inspect the authority, state handoffs, and recovery behavior across them.
Deployment, policy, and runtime changes can affect health, traffic, evidence, status, and recovery. The operating model should make those relationships explicit.
Infraveil's operating model coordinates a defined set of deployment, runtime, evidence, and recovery responsibilities while allowing specialized systems to remain where needed. The practical question is whether that coordination reduces manual work without hiding authority, state, or exit boundaries.
Use bounded evidence, current documentation, and signed commitments.
Review current runtime behavior, customer-key approval, machine signatures, package verification, tenant and operator controls, receipts, data handling, degradation, export and removal paths, recovery limits, customer responsibilities, and signed commitments.
Adopt the platform only when those boundaries and the observed validation record meet the needs of the intended environment.