Read each detail in the context where it operates.
Behavior customers can observe or inspect on enrolled hosts, including local state, workload supervision, and runtime evidence.
Management-plane behavior delivered by Infraveil, including accounts, workspaces, coordination, and operational views.
A sequence or configuration used to explain the model. Exact fields, timing, and thresholds can differ by product version or deployment.
Behavior that depends on plan, operating system, customer configuration, network policy, or an agreement for a particular deployment.
A hosted manager coordinates a customer-side runtime.
Hosted serviceInfraveil is not an entirely local product. The management UI and coordination services are hosted; launcher, agent, workload execution, caches, receipts, and managed workspaces can operate on customer-controlled machines. Operational metadata and evidence cross that boundary to provide the service. Legacy Python payloads may execute from memory, while manifest-defined and supervised services use managed workspace and cache storage on the customer host.
Operator browser — dashboard, approval intent, evidence review
↓ Trust boundary A: human session and hosted application
Hosted management / control plane — identity, workspace coordination, desired state, artifact and command metadata, received evidence
↓ Trust boundary B: authenticated machine channel
Customer host: launcher — machine enrollment, local coordination, agent lifecycle
↓ Trust boundary C: runtime artifact and process authority
Agent / service supervisor / gateway — workload materialization, health, routing, bounded actions, local evidence
↓ Trust boundary D: application process, persistent paths, and external dependencies
Customer workload and data stores
Independent approval path: customer Trust Console → exact release-hash signature → approval service
Authority split
The hosted side expresses intent and aggregates state. Customer-side components materialize permitted changes locally under the selected trust and policy path.
Machine channel
Enrolled hosts authenticate management traffic and report observed state. Customers can observe successful sync, stale state, and local runtime behavior on their hosts.
Hosted internals
Regional layout, availability targets, disaster recovery, retention, and tenant controls depend on the current service and applicable agreement.
Each component has a distinct responsibility.
| Component | Boundary and responsibility | Context | Customer responsibility |
|---|---|---|---|
| Hosted management plane | Accounts, workspaces, desired state, coordination, operational views, and product workflows. | Hosted service | Manage users, workspace access, configuration, and plan-specific controls. |
| Launcher | Enrolls the host, synchronizes assigned intent, coordinates the local agent lifecycle, and reports host state. | Customer-visible runtime | Provide a supported host, network access, service identity, and appropriate operating-system permissions. |
| Workload agent / supervisor | Prepares managed runtime state, supervises services, applies supported policy, and reports observed state. | Customer-visible runtime | Own application behavior, dependencies, secrets, persistent data, and workload-specific recovery requirements. |
| Release approval | Lets customers apply a signature gate to selected releases and choose manual, allowlisted, or automatic approval behavior. | Customer-visible runtime | Protect the approval key and select a mode that matches the required review boundary. |
| Gateway and operational views | Connect traffic, health, incidents, status, service ownership, and recovery information. | Hosted service and customer-visible runtime | Validate routing, exposure, health definitions, alert thresholds, and recovery behavior for each service. |
Bootstrap is a capability, not permanent authority.
Customer-visible runtimeEnrollment gives a host scoped machine identity and configuration for the selected workspace. Local runtime files and credentials must be protected with operating-system permissions appropriate to their sensitivity.
The launcher coordinates local state but does not replace host hardening. Customers remain responsible for operating-system updates, account security, network policy, backups, and the application secrets and data used by workloads.
Deployment-specificThe current Linux/systemd installation path is elevated and registers the launcher unit to run as root by default. Other service-manager behavior, runtime users, destination paths, and required network access depend on the operating system and deployment model; review the current installation guide before granting that authority.
Container-only, rootless, Kubernetes-native, fully air-gapped, Windows, and macOS behavior should be treated as deployment-specific unless current product documentation states otherwise.
infraveil.json expresses intent; runtime evidence reports reality.
Customer-visible runtimeinfraveil.json is the customer-owned runtime contract for services, routes, health checks, order, persistence, restart behavior, and environment requirements. Version it with the application and review it like code.
{
"services": [{
"name": "api",
"command": "./start-api",
"health": { "path": "/health" },
"restart": { "policy": "bounded" },
"persistent_paths": ["./data"]
}],
"routes": [{ "host": "api.example.com", "service": "api" }],
"order": ["api"]
}Conceptual field names only. This block is not the published schema and must not be copied into production without the actual validator.
Hosted service: versioned intent, artifact identity, service definitions, placement, rollout stage, and policy selected by the operator.
Customer-visible runtime: what the launcher and agents report about versions, processes, health, capacity, queues, and failures.
The difference between intended and observed state. Bounded actions continue until the two converge or an explicit failure stops progress.
Deployment-specific: use the validator and compatibility guidance published for the product version you deploy.
Intent becomes execution through explicit gates.
- 01 · Hosted service
Resolve
Resolve workspace, target host, manifest revision, artifact identity, policy, and operator intent.
- 02 · Hosted service
Issue
Record desired state or a bounded command with issuer, target, reason, and correlation identity.
- 03 · Customer-visible runtime
Synchronize
An enrolled machine obtains assigned intent through an authenticated channel and reports its current state.
- 04 · Customer-visible runtime
Validate
Check artifact identity, integrity, applicable approval, compatibility, and local preconditions before execution.
- 05 · Customer-visible runtime
Materialize
Prepare managed workspace and cache state, start or replace processes, and update routes in an ordered transition.
- 06 · Customer-visible runtime
Observe
Collect bounded health and runtime evidence; distinguish running from healthy and reachable from current.
- 07 · Shared operating state
Converge or stop
Promote after acceptable evidence, retry within a budget, roll back, quarantine, or leave an explicit failure.
- 08 · Deployment-specific
Timing
Poll intervals, health windows, restart counts, batch size, and promotion thresholds must be configured and measured; no universal values are asserted here.
Deployment-specificOrdering, retry, compatibility, and partial-recovery behavior can vary by product version and service configuration. Validate the relevant transition under failure before using it for a critical workload.
Two control systems. Do not collapse them into one “approval mode.”
Release-hash approval
Customer-visible runtimeThe release-approval workflow uses a customer-held signing key to approve an exact release hash for selected deployment paths. Customers should validate the gate on the path they intend to use.
| Mode | Customer-controlled behavior | Review boundary |
|---|---|---|
| Manual | Prompts before signing each pending release hash. | Preserves a per-release customer review step while the approval key remains independently controlled. |
| Exact-hash allowlist | Signs only hashes the customer placed on the allowlist. | Moves review earlier; allowlist maintenance becomes security-critical. |
| Automatic | Signs every control-plane-requested hash while enabled. | Does not preserve a per-release human veto while enabled. |
AI proposal and remediation handling
The assistant summarizes evidence and proposes a change; a person decides whether to apply it.
Supported low-risk steps may be assisted while gated categories still require a deliberate decision.
A configured policy may permit a supported proposal class to apply without per-action review. Available categories and safeguards are deployment-specific.
Hosted serviceAssistant requests are evaluated through the same workspace, target, permission, and policy boundaries as other operational actions.
Customer-visible runtimeCustomer-side components apply only the actions delivered through supported control paths and expose the resulting runtime state. An assistant is an interface to those controls, not an independent authority or a security sandbox.
Integrity, authenticity, approval, and freshness answer different questions.
TLS protects the network path. It does not by itself establish who selected or approved an artifact.
A cryptographic digest detects whether downloaded bytes differ from the expected artifact.
A vendor signature establishes that release metadata was signed by the expected Infraveil release identity.
For selected paths, the customer's key approves an exact release hash under the configured approval mode.
Deployment-specificKey rotation, revocation timing, artifact retention, anti-rollback rules, and behavior for expired metadata depend on the current release workflow and customer configuration.
A record proves only what its inputs can establish.
Customer-visible runtimeOperational receipts correlate requested actions with the target, artifact identity, timestamps, reported result, and subsequent runtime evidence where supported.
Important limitA receipt establishes only what its inputs report. Approval, authenticity, transfer integrity, execution, and healthy outcome are separate questions and should not be collapsed into one success label.
| Question | Supporting record | Important limit | Context |
|---|---|---|---|
| Was it approved? | Customer signature over the exact hash and an approval record. | Does not show that the bytes executed or succeeded. | Customer-controlled gate |
| Is it intact? | Digest equality for the bytes obtained. | Does not show who selected or approved them. | Customer-visible runtime |
| Did it execute? | Machine acknowledgement and local process evidence correlated to artifact identity. | Does not establish a healthy outcome. | Customer-visible runtime |
| What was the outcome? | Health, exit, route, request, and application evidence tied to the receipt. | Depends on reliable correlation and service-specific health definitions. | Shared operating state |
Hosted serviceQueued, acknowledged, completed, failed, revoked, and reverted states connect management intent to reported runtime outcomes. A hosted revocation record does not establish that an offline host has already received and applied it.
Document the data path before trusting the control path.
| Data class | Origin → destination | Persistence | Purpose | Customer control |
|---|---|---|---|---|
| Account and workspace metadata | Browser → hosted plane | Hosted | Identity, tenancy, coordination | Manage users and workspace settings |
| Desired state and commands | Hosted plane → customer host | Hosted and local runtime state | Reconciliation and bounded operations | Choose configuration and approval mode |
| Machine identity | Customer host ↔ hosted service | Local credential plus hosted verification state | Authenticate machine traffic | Protect and revoke enrolled hosts |
| Runtime health and evidence | Customer host → hosted plane | Local and hosted subsets | Status, diagnosis, and reconciliation | Configure collection and review plan-specific retention |
| Workload artifacts | Release service → customer host | Managed workspace, cache, and persistent paths | Execute and recover selected versions | Own code, data, secrets, and storage policy |
Deployment-specificResidency, redaction, encryption at rest, backup scope, deletion timing, support access, and legal retention must be confirmed for the current service and applicable agreement.
Recovery is bounded and configured, never guaranteed.
| Failure | Expected bounded response | Context | Validate |
|---|---|---|---|
| Management plane unreachable | Retain explicit local state, avoid unbounded change, and report stale coordination after reconnect. | Customer-visible runtime | Offline duration, command expiry, and reconnect ordering |
| Customer approval absent | Keep a selected release pending when its signature gate requires approval. | Customer-controlled gate | Every deployment path intended for production |
| Process crash loop | Apply a restart budget, stop thrashing, and preserve the observed failure state. | Customer-visible runtime | Thresholds, backoff, escalation, and alerting |
| Bad candidate release | Fail configured health gates and restore a previous version where rollback is configured and compatible. | Deployment-specific | Data migrations, persistent state, and rollback compatibility |
| Disk full or local corruption | Stop unsafe writes, surface degraded state, and recover from a known source. | Customer responsibility | Quotas, cleanup, backup, and repair procedures |
Illustrative exampleA conservative rollout is candidate → validate → customer gate if configured → limited exposure → health window → bounded batches → promote. Batch size, timing, health definitions, and rollback triggers remain service-specific.
What customers can expect, and what remains deployment-specific.
- Hosted service: accounts, workspace coordination, desired state, operational views, and product workflows are provided by Infraveil.
- Customer-visible runtime: launcher and agent behavior, local workspaces, service processes, health checks, and runtime state can be inspected on the customer host.
- Customer control: application code, infrastructure accounts, host hardening, secrets, persistent data, network exposure, and user authorization remain customer responsibilities.
- Deployment-specific: retention, residency, recovery targets, role granularity, regional layout, support access, and private deployment options must be confirmed for the current offering.
- Validation: architecture explains the mechanism; customer tests and observed runtime evidence establish behavior in a particular environment.
Scope limits
This page does not claim that every deployment supports fine-grained enterprise RBAC, full air-gap operation, active-active management-plane mirroring, a particular region, or a contractual availability or recovery target. Confirm those requirements against current product documentation and the applicable agreement.
Validate the behavior that matters in your environment.
- 1. Confirm the boundary.
Identify what runs on the customer host, what is hosted, and which operational data crosses between them.
- 2. Exercise release approval.
Test the selected manual, allowlisted, or automatic mode and document where human review occurs.
- 3. Observe storage.
Confirm the local workspace, cache, persistent paths, permissions, cleanup behavior, and backup implications for the workload type.
- 4. Interrupt coordination.
Disconnect the hosted management plane and observe workload continuity, stale-state labeling, reconnect behavior, and bounded local authority.
- 5. Drill failure and recovery.
Fail health checks, exhaust a restart budget, and test the configured rollback or stop behavior.
- 6. Review responsibility.
Confirm ownership of secrets, host hardening, retention, incident response, exports, backups, and offboarding before production use.
The test is not whether the dashboard looks authoritative. It is whether intent, identity, bytes, execution, and outcome remain distinguishable when a dependency fails.