Identity Verification Privacy.
In plain language.

Identity verification is required before you can apply seals on behalf of a professional license. The goal is narrow: confirm that the human sitting behind the account matches the person the licensing board issued the credential to. This is a one-time process per credential, not a recurring surveillance tool.

The barcode on the back of a US driver's license or state ID carries a standard set of fields. We decode it and take three:

• Name — to compare against the licensee on record with your board.
• Expiration date — so an expired document does not pass.
• Issuing jurisdiction — the two-letter state or province code.

The barcode also contains your date of birth, document number, address, height, and eye color. Our decoder has nowhere to put them. Those fields are never extracted, so they cannot reach our application, our database, our logs, or an error report — not because we promise to delete them, but because nothing ever pulls them out of the barcode. To be exact rather than flattering: the barcode as a whole is decoded in memory for the moment it takes to find the name, so "never extracted" is the honest claim, not "never read".

We do not ask for and do not collect:

• A selfie, a liveness video, or any face-match check.
• Biometric templates of any kind.
• Social Security Numbers, TINs, or other tax identifiers.
• Device fingerprints or network-level identifiers beyond standard request metadata.

Most identity checks work by sending your ID somewhere — a vendor, a model, a review queue — and then promising to delete it later. Deletion is a promise about the future. We wanted a claim about the present, so we built it differently:

1. You upload a photo of the back of your ID.
2. The bytes stream into one short-lived process on our server. They are not written to a temporary file, which is what a web framework would normally do by default.
3. The barcode is decoded on that same machine, by code we compiled ourselves. No API call, no third party, no model. Your ID is never forwarded anywhere else — it goes from your browser to one machine, and stops there.
4. The name is compared against the licensee your state board has on record for the license you claimed.
5. The process shuts down. The memory holding the image and everything decoded from it is released, and nothing anywhere still refers to it. What remains is a yes or a no on your account.

This runs on Erlang, which Ericsson built to keep telephone switches running for years without stopping. Its processes hold state in memory for exactly as long as the work lasts, and that state goes away with the process. Your ID is held that way: while it is being read, and not afterwards.

A practical consequence worth stating plainly: if you ask us to produce a copy of an ID you uploaded here, we cannot. Not as policy — we do not have one. That is true of this web flow, which is where identity checks run today. It is not true of the older code path described at the end of §04, which does keep the image; if you have ever submitted an ID through anything other than this page, ask us and we will tell you what exists.

That last row is not ID data — it contains nothing read off the document — but a page titled "What We Keep" should say it exists. Every upload notifies a person on our side so that a check needing human judgement is not left sitting. Sending that notification writes a delivery record, and queues a background job carrying the same fields.

Those are enforced by timers, not by intention. A completed check is over in seconds. An upload that goes quiet — you closed the tab part-way — is killed after two minutes of inactivity. And no session may live longer than fifteen minutes under any circumstances, which is the ceiling that exists so a very slow connection can still finish a large photo.

If a check cannot be decided automatically, nothing is held in memory waiting for us. The session ends the same way it always does, and we contact you to sort it out directly.

This describes identity checks performed on the web, which is where the flow runs today. An older code path used by unreleased native builds stores the submitted image on our server for staff review, and does not currently delete it afterwards. Nothing in the shipping product uses that path, and it is being replaced by the flow described above.

Re-verification is not punitive — it confirms that the person holding the account is still the licensed professional we checked the first time. We tell you what triggered it.

Every re-check is the same procedure described in §03: read the barcode in memory, compare the name to your board record, discard the image. Because nothing from the first check was retained, a re-check is a fresh read, not a comparison against a stored copy.

What we have built so far is the check itself and the ability to require it again. We have not built automatic triggers, scheduled re-checks, or notification flows, and we would rather say so than describe them here as though they exist. Today a re-check happens because a person decided it should — most often after a report of a lost device or a change at the licensing board — and we contact you directly when it does.

Documents you sealed before a re-check remain valid. A pending re-check holds your account at the verification step until it is completed.

If you believe a re-verification request is fraudulent (a phishing attempt spoofing us), ignore the message and sign in directly at https://engineeringid.com — the legitimate prompt will be waiting for you there.

• Access — we will tell you what we hold, which for identity is the result of the check, when it happened, and the internal alert described in §04. There is no image or extracted field to send you, because none was kept.
• Deletion — there is no stored ID to delete. You may ask us to clear the verification result, though doing so means you can no longer issue seals until you pass a check again. Records of seals you already issued are retained as audit evidence, as the profession requires.
• Correction — if the check reached the wrong conclusion, tell us and we will look at it. We cannot correct a stored name or date of birth, because we never recorded one.
• Re-verification — ask us to run the check again, for instance after a name or license change. There is no self-serve button for this yet; write to us and we will reopen it.

Contact [email protected] and we'll respond within 30 days.

Checks fail for ordinary reasons: a blurry or cropped photo, a glare on the barcode, an expired document, or a name that does not match what your board has on record. In every one of those cases the image is discarded exactly as it is on success — there is no failure path that keeps it, and no retention window to wait out.

You can retake the photo. After three failures we stop asking you to try again and take a look ourselves; you will get an address to write to, and nothing of yours sits in memory waiting while that happens.

Until the check passes, your account is held at this step and the rest of the app is out of reach — that is the point of the check, and we would rather say so plainly than imply it only affects sealing. A failed attempt is not a mark against you, and we stop counting attempts once a person has looked at it.

A name mismatch is not an accusation. Names change, boards record them inconsistently, and our automatic comparison is deliberately conservative. If it happens to you, we sort it out by hand.