How it works
The architecture follows from the requirements.
Each component exists because the truth established by the previous step is not enough to support the next one honestly.
- 1
An EAID is assigned.
The identification is governed and associated with a participant the organization already knows. It does not self-authorize.
- 2
Assigned authority is reached.
The EAID presents to its Authority Server and must establish fresh runtime authority for the current session.
- 3
Presence is observed independently.
The organization-controlled Existence Beacon and Oracle evaluate the live relationship rather than inheriting presence from identity or application activity.
- 4
Private interaction is released.
Only after the first successful presence determination does the uniquely serialized private Rendering Agent open.
- 5
Presence remains current.
Continuous validation renews the condition. Runtime authority remains volatile rather than becoming permanent historical trust.
- 6
Absence has consequence.
If required authority or validation fails, trusted continuation collapses and selected protected actions no longer proceed.
Two independent channels
Trust is separated from protected content.
Channel A carries authentication, session authority, continuous validation, presence determination, and collapse signaling.
Channel B carries the organization’s application activity, protected content, and user interaction.
The presence system does not need to inspect protected documents, transactions, or communications in order to determine whether trusted interaction may continue.
Organizational authority
The organization remains in control.
The organization determines who is authorized, which roles apply, what actions require presence, and what consequence follows absence. Its Existence Beacon retains presence records, session history, policy, and operational evidence.
Existence supplies the condition. It does not assume ownership of identity, data, applications, or business decisions.
Examine the relationship