Protected actions
A protected action is the point where valid authority is about to become consequence.
Login is not the only consequential decision. Applications approve payments, release data, alter permissions, deploy code, delete records, change infrastructure, and authorize physical or digital operations. Existence research places the current present-or-absent condition at the function that is about to act.
The function boundary
Protection becomes precise when it is attached to the action that must not proceed under absence.
The organization identifies the bounded function, determines which credentials and permissions are required, and defines the consequence of the current existence result.
verify_existence(...)The application asks for the maintained condition immediately before the selected function commits its consequence.
Authority remains separate
A present result cannot authorize an otherwise forbidden action.
The participant must still satisfy the organization’s credential, identity, role, approval, and workflow requirements. The EAID is not an access credential, and a found identification cannot be allowed to grant application authority.
Existence is an additional current condition. It is not a shortcut around access control.
Private arrival first
The organization consumes existence only after establishment is complete.
The first successful heartbeat releases the Rendering Agent. The organization loads its page, completing existence establishment. That page then applies the organization’s own credential and authorization requirements.
After arrival, existence maintains itself through recurring heartbeat. The application can observe the result wherever a protected action is defined.
Current consequence
The important question is not merely whether access was granted earlier.
A valid session can outlive the immediate moment of authentication. A workflow can remain open while the participant leaves. A queued approval can be executed after the condition under which it was prepared has changed.
A current existence check allows the organization to require that the governed relationship still returns present when the action becomes irreversible or externally consequential.
Failure must be designed
ABSENT is not an error message; it is the other scientific result.
The organization must determine whether absence blocks, pauses, rolls back, saves state, terminates a session, requires re-establishment, alerts an operator, or invokes another controlled path.
The scientific result is binary. The operational response may differ according to the action, risk, regulation, and business process.
Observation point
The network is where the application observes existence, not where existence originates.
The maintained condition is returned into the organization’s environment for use. The network carries the observation and the application consumes it.
Describing the network as creating presence would confuse the observation path with the existence relationship being observed.
What existence does not prove
A present participant can still request the wrong action.
Existence does not establish intent, understanding, accuracy, legality, freedom from coercion, safe content, correct configuration, or successful review. It does not replace dual control, transaction limits, validation, fraud detection, or human judgment.
It establishes only the bounded current condition required before the organization allows selected authority to become consequence.
Continue the examination