E-01
Consent + intent
The affirmative signer decision and the policy context that requested it.
Legal / technical control note
Electronic-signature controls and evidence.
Private-beta signing flows are designed to capture intent, bind a signer event to a document, protect the stored record, and preserve the related evidence. The exact path depends on configuration.
This is a technical control mapping—not legal advice, certification, or a blanket determination of ESIGN, UETA, eIDAS, HIPAA, GLBA, or other legal compliance.
Evidence model
What a configured flow is designed to retain.
E-02
Signer reference
The identity or credential reference used by the configured verification path.
E-03
Document digest
A cryptographic digest that binds the signing event to the reviewed document version.
E-04
Decision history
Request, review, refusal, completion, and provider events retained as a linked history.
E-05
Protection metadata
Encryption, device-verification, and timestamp references when those controls were actually applied.
E-06
Provider handoff
A durable reference when a qualified, notarized, or unsupported requirement is sent to an external provider.
Control mapping
Support and limitation, side by side.
| Control area | Designed support | Important limit |
|---|---|---|
| Intent and consent | Signing policies can require affirmative intent and applicable electronic-record consent before a native flow proceeds. | A captured event does not establish that electronic signing is permitted for every document, party, or jurisdiction. |
| Attribution and document binding | Configured flows can use signer identity references, WebAuthn or device-backed verification, and a signature bound to the document hash. | Available verification depends on the signer, device, browser, deployment, and configured credential path. |
| Record protection | Document records can be encrypted per document and linked to a chained signing-event and evidence history. | Encryption and tamper evidence reduce risk; they do not make a record immutable or guarantee admissibility. |
| Retention and access | Policy packs can attach retention and record-access requirements, while active legal holds are designed to prevent ordinary rotation. | There is no universal LumeGrid retention period. The governing agreement and applicable law determine the required schedule. |
| Time evidence | Flows can attach trusted timestamp or OpenTimestamps evidence when a configured service returns it. | A timestamp may be absent when no service is configured or available; this page does not claim universal RFC 3161 coverage. |
| Qualified or notarized signing | Requirements outside the supported native path can be routed to a configured electronic-signature or notarization provider. | LumeGrid does not represent itself as a qualified trust-service provider or notary on this page. |
Deployment responsibility
Legal validity depends on the transaction—not the presence of a feature.
The deploying organization is responsible for document eligibility, required disclosures, consent, identity assurance, access to retained records, exclusions, retention, provider selection, and local law.