Skip to main content
Guard separates four questions: which server is connected, who may request a change, which executor owns the effect, and what evidence shows its outcome. Keeping them separate matters when a server restarts, a connection drops or a client retries a request. This is an architecture explanation. The published reference identifies its release; the installed version and qualified transport determine available behavior. Availability describes the public and preview scope.

​
Identity is not permission

Enrollment binds a server to its intended Techstack installation. Guard’s host-key design makes that binding depend on a key generated on the server, instead of treating a copied bearer credential as sufficient host identity. Server identity, the application owner and a user’s sign-in are different facts. The published worker reference exposes identity inspection and upgrade operations. A legacy bearer-only binding is observe-only until the proposed host key is approved through the documented owner flow. Listing a key or discovering a server grants no additional rights. Even an authenticated Guard must receive an operation admitted for the correct resource, capability and server generation. A replacement server must not inherit permission to replay an old server’s commands.

​
One request, one durable operation identity

The durable HTTPS command profile is designed around this sequence:
1

Admit the operation

Techstack admits a command bound to the intended target and payload.
2

Preserve intent before the effect

Guard records the intent durably and checks the server generation.
3

Execute through the owner

The owning executor performs the typed operation and returns its result and verification evidence.
4

Preserve the outcome before delivery

Guard records the outcome, then delivers the original result to Techstack.
5

Acknowledge the same result

Techstack durably acknowledges that exact command and result identity.
The intent binds the command identity, target generation and payload digest before a side effect. The local journal preserves an outcome before delivery. A retry can redeliver the original result without authorizing another execution. Fencing prevents an obsolete process or generation from continuing a mutation. This is not a generic exactly-once guarantee. If the system cannot determine whether an effect happened, guessing success or blindly repeating it can both damage the server.

​
Uncertainty stays visible

The released worker operations describe unresolved outcomes and their reconciliation. An unresolved outcome fences further changes. A timeout can change how the issue is presented to an operator; it does not itself release the fence. An authorized resolution records whether the effect was verified as applied, verified as absent, or explicitly accepted as still unknown. It includes the actor and a revision check. Accepting uncertainty permits progress but does not retroactively turn an unknown operation into a successful one.

​
Bounded execution and privilege

Guard supervises typed operations through the executor that owns them. StackKits owns the host baseline and application lifecycle. Techstack owns provider operations and coordination. Guard does not create a second lifecycle or use a general remote shell as a substitute for those contracts. The Linux privilege-split design runs the Guard daemon unprivileged and delegates admitted privileged effects to a restricted executor. That executor remains a sensitive boundary: permitted operations can materially change the host. Privilege isolation depends on the supported operating-system profile and its qualification, rather than applying automatically to every installation.

​
Transport security and operation reliability are separate

HTTPS polling and gRPC/mTLS are distinct transport profiles. Encryption and a valid certificate do not by themselves prove journal durability, generation fencing or binding to the host key. The gRPC/mTLS profile is not qualified for the durable HTTPS profile’s full Guard guarantees. Similarly, a heartbeat establishes recent contact. It does not prove that an authenticated command and its result completed a round trip, that the baseline is current or that an application is recoverable. Read protection and recovery evidence for how these operation guarantees relate to the state of your services.