Email one-time-code identity
One-time codes are hashed with a server secret, expire after ten minutes, are single-use, and have an attempt cap. A successful cast uses one verified email address for one campaign uniqueness boundary.
Integrity and trust
What can I trust now?
A result is useful only when its identity source, counting rule, response obligation, and limits are stated plainly. This page separates current controls from setup gates, product Direction, and claims player.vote does not make.
Available-now control summary
The declared rule stays attached to the result.
These controls run in the current product. They do not depend on a future enterprise programme.
One identity modeEmail or approved partner assertion per campaign
Immutable rulesOptions, method, and eligibility fix at open
Hidden scoresLive scores remain withheld by default
Append-only auditLifecycle changes remain inspectable
Visible outcomeResponse and outcome stay with the contract
Available now
Committed controls that run without an enterprise promise.
The complete decision path uses the same identity, counting, reveal, response, and export boundaries.
Available now
Immutable open decision rules
Options, method, identity mode, and eligibility cannot change underneath participants after the decision opens.
Hidden live scores
Scores remain withheld while a decision is open by default, while turnout can remain visible.
Invite allowlists
A host can restrict a campaign to the declared email set and can attach groups for result breakdowns.
Atomic count and uniqueness
The cap check, participant link, voter identity, and ballot write share the same commit boundary. Invalid ballot data does not consume a valid partner token.
Audit, export, response, and outcome
Append-only lifecycle events, CSV export, the company response, and the recorded outcome remain attached to the original contract.
Available with setup
Current controls that depend on configuration or approval.
These are not Direction claims. Each path exists, but a host or operator must complete the stated setup.
Approved issuer assertions
An approved backend can mint a five-minute, campaign-bound voter token for one stable partner subject. Issuer approval remains manual because the assertion label is a claim about that issuer.
Global participant account
A participant can return across client relationships. Each client sees only its own scoped relationship, not the global participant identifier.
Signed lifecycle delivery
Signed webhook delivery, retries, replay, and rotation exist. Production delivery requires a signing root and exact hostname allowlist.
Scoped server authority
Show-once API keys use exact scopes for campaigns, participant relationships, grants, and voter-token minting. Browser Origin requests are refused.
Exact-origin framing
Client-bound embeds use exact registered origins, strict frame policy, a source-checked message handshake, and memory-only partner tokens. Safari and a production sibling-domain deployment are not yet verified.
Custom public-record hostname
The host must prove the TXT claim, point the CNAME, and wait for an active certificate before the hostname can serve the record.
Identity limits
What this does not prove.
Verification raises the cost of duplicate or unauthorised participation. It does not turn an identifier into a verified human.
One verified email is not one verified person.
Aliases, disposable addresses, and shared inboxes remain possible. Use an allowlist or approved partner identity when the electorate needs a stronger boundary.
A partner assertion is only as strong as its issuer.
player.vote binds and records the approved issuer subject. The issuer still owns its account controls and the truth of that subject.
The host defines who should participate.
player.vote enforces the declared electorate. It cannot prove that the host selected the right people or interpreted the evidence well.
Browser and deployment proof still matters.
The scoped embed has been exercised in Chrome and Firefox with third-party cookies blocked. Safari and a production sibling-domain deployment are not yet verified.
Data and authority
Export, deletion, and management authority stay explicit.
A management route is an authority boundary, not a convenience link.
Decision evidence remains portable
Hosts can export results, ballots, group breakdowns, and the audit log as CSV. Exports exclude authentication secrets and management capabilities.
Access revokes before data purge completes
Deletion revokes active access and removes decision, ballot, relationship, and host personal data under the current deletion path. Historical ballot boundaries are not rewritten to permit a second ballot.
Signed-in hosts recover account-owned decisions
Account-owned decisions remain available through the signed-in host workspace.
Legacy and anonymous decisions use a scoped capability
A legacy or anonymous decision relies on its campaign-scoped manage capability until the host claims it. The raw link exchanges for a scoped HttpOnly cookie and redirects to a clean URL.
Treat the capability like a password
The emergency management link remains sensitive. Anyone holding a still-valid capability can exercise its campaign authority.
Enterprise controls, not built yet
Direction
Accepted product direction, not current capability.
Multi-seat roles, administrator SSO or SAML, workforce provisioning, retention policy, and broader enterprise administration are not built yet.
Claims not made
No borrowed certification or uptime claim.
These statements are limits, not promises that a certification programme will arrive on a particular date.
No SOC 2 claim
player.vote does not claim SOC 2 certification.
No ISO 27001 claim
player.vote does not claim ISO 27001 certification.
No public uptime claim
player.vote does not publish a public uptime or status claim because no public status page exists.
Use the declared boundary
Create the contract or inspect the complete technical rules.
Choose the identity source, electorate, method, response, and outcome promise before participation begins.