Credentials

Your license is a first-class object

A license is not a string field on a user record. It has a state machine, a renewal cycle, an issuing board, a region, and an expiration that we have to honor at the moment of sealing — not a label we display on a profile page. We treat the credential as the asset it is, with its own lifecycle and its own gate.

Executive summary

Each credential is a row with a strict state machine: claimed → pending verification → verified → expired / suspended. The sealing gate checks current state at the moment of signing — an expired or suspended license fails before any cryptographic operation runs.

Verification flows through the issuing licensing board via direct integration with state boards' license-lookup endpoints — not just an upload-a-photo claim. Renewal tracking surfaces upcoming expirations so a lapsed license never produces a valid-looking seal in your name.

Our commitments

Five rules for the credential

01

The license is the asset, not the user record

Credentials have their own lifecycle, their own audit trail, their own state machine. A user can hold many; a credential can outlive a user record's mood.

02

Verification is board-sourced, not self-asserted

Verification flows through the issuing licensing board. We do not stop at 'user uploaded a JPEG.' The board is the canonical source.

03

The sealing gate checks current state, every seal

Expired, suspended, or not-yet-verified credentials fail the gate before the cryptographic operation runs. Backdated seals against expired licenses are not possible.

04

Renewal alerts are non-optional, not nag-style

Renewal reminders are scheduled at sensible intervals before expiration. Once expired, sealing is blocked — no grace period, no appeal.

05

Credential changes are first-class audit events

Every state transition (claim, verify, suspend, renew, expire) is a hash-chained audit event with actor, source, and reason.

Implementation — the lifecycle

The credential state machine

Initial state :claimed User has asserted ownership; not yet verified
Verification state :pending_verification Submitted to issuing board for confirmation
Active state :verified Board has confirmed; can be used for sealing
Expired state :expired Past expiration_date; sealing gate fails
Suspended state :suspended Active board action against the license; sealing blocked
Renewal tracking expiration_date Notifications scheduled before expiration
State transitions Audited per change Hash-chained event with actor, source, before/after state
Per-org isolation Per-credential scope A credential held at one org does not bleed into another

Implementation — board verification

How verification flows through the issuing board

State licensing boards Direct integration with state lookup endpoints Engineer credentials verify against issuing-board endpoints today; other professions verify via Manual / StateAPI / Integration paths
National-registry vendors On roadmap Vendor-side cross-state registries are on the roadmap; not currently wired
Manual review path Customer-facing review When automated verification is not available, customer admins approve with documented evidence
Verification frequency Periodic re-check Re-verifies on a cadence; status-change events on transition
Failure handling Status flagged, sealing blocked Verification failures do not silently degrade — sealing is gated until resolved

The full picture

What is built, what is being built, and what we chose not to build

Live today

Per-credential lifecycle state machine

Live

Strict transitions; expired/suspended credentials fail the sealing gate.

Direct state-board verification

Live

Engineer credentials verify against issuing-board endpoints today; other professions use Manual, StateAPI, or Integration paths.

Renewal tracking with scheduled reminders

Live

Notifications before expiration; sealing blocks once expired.

Per-credential audit trail

Live

Every state transition is a hash-chained audit event with actor, source, before/after.

Sealing-gate enforcement at every operation

Live

Current state checked at signing time, not just at credential entry.

Building now

Continuing-education (CE) hours tracking

Building now

Per-license CE requirement tracking with provider integration. We plan to gate renewal on CE evidence in CE-enforcement states.

Scoped to states with CE-enforcement boards.

Multi-discipline credential bundles

Building now

A single user holding PE, SE, and architecture credentials across states — bundled view, per-credential rules.

Customer-uploaded supporting documents

Building now

Wallet-card image, board-issued certificate, CE transcripts attached to the credential record with the same encryption rules as everything else.

Roadmap

Cross-state reciprocity awareness

Roadmap

Surface which states accept which other states' licenses for sealing under reciprocity agreements.

Specialty endorsements

Roadmap

Track sub-discipline endorsements (e.g. structural, transportation) within a parent PE license.

Continuing-education provider integrations

Roadmap

Pull CE attendance directly from approved providers instead of manual upload.

Considered & rejected

"Self-attested" credentials with no verification

Considered & rejected

A credential the issuing board has not confirmed is not a credential — it is a claim.

Why we rejected it: the seal carries legal weight specifically because the credential behind it is verified. A self-attested layer that produces real-looking seals would undermine the whole platform. We do not ship the appearance of verification.

Grace-period sealing on expired licenses

Considered & rejected

An expired license cannot legally seal. A grace period is a tool for evading that fact.

Why we rejected it: regulatory bodies do not give engineers a "we forgot to renew" grace period. Neither do we. The renewal alerts give the engineer plenty of warning; once expired, sealing stops.

Cross-customer credential sharing

Considered & rejected

A credential is bound to the licensed individual, not the firm or organization.

Why we rejected it: every "let an admin assign credentials to subordinates" is a way for one person to seal in another person's name. The credential lives with the licensed individual; firms see it through the membership relationship, not by ownership.

Storing the original wallet card image and using it as the visual stamp

Considered & rejected

Photographs of physical stamps look like photographs at any zoom. Vector renders look like ink.

Why we rejected it: a digital seal that is a low-res scan undermines the professionalism of the signed document. We render a vector stamp at seal time. The wallet card image is a verification artifact, not the visual asset.

Compliance mappings

Controls this surface satisfies

SOC 2 CC6.2

User Access Management

Per-credential lifecycle gates sealing access

ISO 27001 A.9.2.5

Review of user access rights

Periodic re-verification against the issuing board

ISO 27001 A.18.1.1

Identification of applicable legislation

Per-region license verification respects state-specific requirements

State licensing board rules Varies

Active license required for sealing

Sealing gate enforces state-specific active-license requirements

21 CFR Part 11 11.10(d)

Limiting access to authorized individuals

Sealing requires a current, verified credential

For compliance teams

Questions you do not need to call to ask

What happens when a license expires mid-project?
Sealing is blocked the moment the credential transitions to :expired. Existing sealed documents remain valid (their RFC 3161 timestamp proves they were sealed while the license was active); new seals against an expired license fail before any cryptographic operation runs.
Which licensing boards do you verify against?
Direct integration with state boards' license-lookup endpoints for engineer credentials, with manual review as the fallback path. Other professions verify via Manual, StateAPI, or Integration paths today; vendor-side national registries are on the roadmap.
How often is verification re-checked?
On a cadence per board — boards that publish change feeds enable real-time updates; boards that require manual lookup re-check periodically. Status changes (suspension, expiration) propagate as hash-chained audit events.
Can an organization admin grant credentials to a member?
No. Credentials are bound to the licensed individual. Members hold their own credentials; the org sees those credentials through the membership relationship. There is no admin path that creates credentials in someone else's name.
What if a board's verification system is down?
The verification timestamp is surfaced to the user so a stale check is visible. Configurable staleness thresholds and last-known-good fallback are tracked as future work; today, sealing relies on the credential's current stored state.
How is reciprocity handled?
Per-state reciprocity awareness is on the roadmap; today, customers configure their own per-state allow-list. The credential record carries the issuing state; the sealing operation checks the project state against the credential's region.

A credential is the asset, not a label

See your credentials managed with the lifecycle they deserve.

Get Started See stamps