Home Privacy architecture Tenant isolation Evidence integrity Engineering practice Assurance What was never built Try it yourself Project story →
Build status  ·  Independent portfolio project

Built, building,
and never.

This page records what was implemented, what testing uncovered, and what would still be required before a system like this could be considered commercially ready. An early prototype claiming a complete security posture has either not looked or is not telling you — so the gaps are listed alongside the work.

Implemented
0
Building
0
Planned
0
Never
0
Why publish the gaps? Because a page listing only what works is not worth reading, and finding the gaps first is the only version of this worth publishing. Everything marked Building or Planned is not available today and should not be read as though it were. Where something is not marked Implemented, that is simply the current state.
Implemented in the current prototype now Building in progress Planned scoped, not started Never deliberately excluded
01 — Privacy

Privacy architecture

Structural rather than procedural — enforced by the database, not by policy.

Implemented
Identity documents cannot be retained
A database constraint rejects any write attempting to store a raw identity payload: CHECK (raw_payload_retained = false). Application code cannot override it.
Implemented
No names, emails or identity documents stored
No candidate-facing table has a name or email column. Candidates are opaque references that only the employer can resolve.
Implemented
Candidate references are hashed for every lookup
The employer's reference is SHA-256 hashed, and the hash is what every session, template and continuity record is keyed on. A readable copy is stored alongside it so a recruiter can recognise their own candidates in a list — it is the employer's own job reference, never a name or contact detail, and it is never the key anything is matched against. An earlier version of this page said the reference was “never held in its original form”. That was inaccurate, and it has been corrected rather than quietly reworded.
Implemented
One face record per candidate, ever
Every re-check is compared against the original anchor and discarded. Twelve interviews still produce exactly one stored template.
Implemented
Legacy image storage retired
An early version of the product wrote webcam snapshots to a storage bucket. The current design streams the second camera live and stores nothing, but the bucket and one image from April survived — reachable by the anonymous browser role, and contradicting the claim above. Removed on 7 August 2026: the policies granting anonymous access were dropped by migration, then the image and the bucket itself were deleted. The account now holds no storage buckets of any kind, so “no images are retained” is no longer a policy being followed — it is a thing the system cannot do. It is listed rather than quietly deleted, because a page that only shows what went right is not worth reading.
Implemented
Provider deletion is tracked, not assumed
Purge is a state machine with retry, backoff, terminal-failure states and an attestation record — not a request fired into the dark.
Implemented
Template encryption at rest
AES-256-GCM envelope encryption, switched on in the current prototype on 7 August 2026. Verified by direct query on both databases after live capture runs: each stored template carries a ciphertext, an initialisation vector and a version marker, and the plaintext field is empty. A continuity check then decrypted a stored template and matched it against a fresh capture on each database, so the round trip is proven rather than assumed — encryption that cannot be reversed would look healthy right up until verification silently stopped working. Both databases were emptied before the switch, so no legacy plaintext template exists anywhere; not one unencrypted record predates it. One key covers the service today — per-tenant keys in a managed key service remain Planned, below.
Planned
Per-tenant encryption keys in a KMS
One key per organisation, managed in a key service with documented rotation, so no single key exposes more than one tenant.
Planned
Automated retention enforcement
Expiry dates are recorded on every record today, but nothing acts on them automatically yet. Scheduled deletion with proof-of-deletion receipts is scoped.
Planned
A non-biometric verification route
Consent given in an employment context is not freely given in the legal sense, and some jurisdictions bar making biometric consent a condition of a hiring process. An equivalent non-biometric path is a requirement, not an option.
02 — Isolation

Tenant isolation

Keeping one organisation's data away from another's — and being precise about what enforces it today.

Implemented
Tenant ownership on every record
Every session-scoped table carries an employer identifier, indexed, with foreign keys enforcing that sessions point at employers and recruiters that actually exist.
Implemented
Every recruiter route checks whose data it is, enforced by a build-failing test
A route that verifies a login has authenticated the caller, not authorised them. On 8 August 2026 an internal review found five routes that verified the session token and then discarded its claims — proving the caller was a recruiter without ever asking which. All five are now scoped to the caller's own employer. The more durable part is the check: a test scans every route on each build and fails if one authenticates a recruiter without using the employer claim, so the next route written cannot repeat it. Found in synthetic data. No real candidate data has ever been held.
Implemented
Row-level security enabled, default deny
Enabled on all tables with no permissive rules, so the database refuses non-privileged access by default.
Implemented
Default public-role permissions revoked
The database platform grants broad default permissions to the anonymous API role — the role behind the key that ships in browser code. Revoked in the current prototype on 7 August, along with the default that would re-grant them on any table created later, and a database-level trigger that strips them from anything new. A build-failing check now runs against both databases on every deployment. It was deliberately merged before the fix, so it failed loudly and enumerated every affected table first — a check nobody has watched fail is not evidence that it works.
Building
Isolation enforced by the database, not the code
Today separation is enforced by application code consistently filtering on the tenant identifier, with the database groundwork in place. Moving enforcement into the database itself — so a missed filter cannot leak — is the largest single piece of work on the roadmap, staged table by table.
Planned
Per-request authenticated database access
Requests execute as the user's identity rather than a service key, confining the privileged key to background jobs and migrations.
Planned
Cross-tenant test suite
An automated proof that an authenticated user of one tenant cannot read another's data by identifier, by reference, or by export.
03 — Evidence

Evidence integrity

The record is the product. These are the controls that make it defensible — and the ones that do not exist yet.

Implemented
Decisions record the rule they were judged against
Every continuity result stores the threshold, model and alignment method in force at the time. Tighten the standard later and past decisions remain interpretable on their own terms.
Implemented
Tamper-evident deletion receipts
Receipts carry a hash and signature; altering one breaks the seal visibly.
Implemented
A receipt cannot exist without the verification it attests to
A seal that anyone can apply is not a seal. On 8 August 2026 an internal review found the endpoint that records a completed identity check had no authentication: a valid, correctly signed receipt could be minted for a session that had never existed. Completion is now refused unless the session is real and its face anchor was already captured — the order the product claims, enforced rather than assumed. Repeated calls return the original receipt instead of issuing another. Found and closed in synthetic data, before any real candidate had been processed.
Implemented
A browser can only report what a browser can observe
The evidence record accepts telemetry from the candidate's device — setup progress, camera state, session end. It previously accepted any event name, which meant a browser could write a record of a decision the server never made. Reported events are now checked against a fixed list of things a client can legitimately witness; anything a server authors — identity outcomes, continuity results, human overrides — is refused with the attempt logged.
Implemented
Receipts signed with a key that does nothing else
Receipts were signed with the identity provider's API credential doing double duty as a signing key — so rotating a vendor secret for ordinary reasons would have silently invalidated every receipt ever issued, and the same key existed in more than one environment. Signing now uses a dedicated per-environment key that signs nothing else. Signatures record which key made them, so a key can be replaced without stranding the receipts issued before it.
Implemented
Human approval required to begin a session
An authorised recruiter must actively approve. This is a step in the flow, not a configuration flag.
Building
Independently verifiable receipts
Receipts today are sealed with a shared secret, meaning only Verlinko can verify them — which is most of the point of a receipt. Moving to public-key signatures, so a receipt could be checked independently of whoever issued it, is scoped.
Planned
Append-only, hash-chained audit trail
Today the audit record is protected by access control rather than by structure. Chaining each entry to the last makes silent alteration detectable rather than merely prohibited.
Planned
Authorization decision log
Recording not only who accessed evidence but who was permitted to — a claim no hiring tool currently makes.
04 — Practice

Engineering practice

How changes reach production, and how mistakes get caught.

Implemented
Database structure is version-controlled code
Every schema change is a numbered, replayable file. The database can be rebuilt from the repository alone — which is also what makes creating an isolated test environment possible.
Implemented
Staging environment at parity
A full copy of the system at the identical schema version. Changes are applied there first, always.
Implemented
Automated drift detection against production
Every schema change compares the live database against what the repository says it should be, and fails if they disagree — on the pull request against staging, and again on merge against production. It has already caught a real divergence — storage rules named "authenticated" that in fact granted anonymous access.
Implemented
Cryptographic code tested on its failure paths
The encryption module is tested by trying to break it: tampered data rejected, wrong key rejected, missing key throws rather than silently writing plaintext. Testing that something fails correctly is rarer than testing that it works.
Implemented
Matching performance measured, not assumed
Separation between same-person and different-person populations is measured on this project's own pipeline and published, including the sample size. You can reproduce it on your own face.
Building
Multi-subject threshold calibration
Current measurements come from a small sample. Calibration across many faces, with false-match and false-reject rates stated at a chosen operating point, is in progress.
Planned
Server-side template computation
Face templates are currently computed in the browser. Moving computation server-side removes the possibility of a tampered client submitting a fabricated template.
Planned
Rate limiting on public endpoints
Not currently implemented.
Planned
Monitoring, alerting and incident response
There is no alerting today. Detection, an on-call path and a documented 24-hour breach-notification commitment are scoped together.
Planned
Second-angle enforcement
Candidates are guided to position the second camera between 110° and 120° during setup, and the interviewer sees both feeds live. Automatic measurement and enforcement of that angle is not built.
05 — Assurance

Assurance & compliance

The honest state of the paperwork a security review would ask for.

Implemented
Outside the EU AI Act's high-risk category
One-to-one identity verification is expressly excluded from the Act's high-risk classification, which covers systems that evaluate candidates. Verlinko verifies identity and does not assess people — and the boundaries below are what keep it that way.
Building
Data protection impact assessment (DPIA)
Mandatory for systematic biometric processing. In preparation, and written so it could be adopted rather than reconstructed.
Planned
SOC 2 Type II
Not held. The observation window is 6–12 months of elapsed time and cannot be compressed. The honest position is to state where that window stands rather than imply otherwise.
Planned
ISO 27001
Not held. Would be sequenced with SOC 2, and prioritised first for deployment in Europe.
Planned
Independent penetration test
Not yet performed. Planned inside the audit window so the results form part of the evidence pack.
Planned
Presentation-attack testing (ISO/IEC 30107-3)
The recognised standard for liveness and spoof resistance, tested by accredited laboratories. Not yet undertaken.
Planned
EU data residency
All data is currently hosted in the United States (US-East). A European region would be a prerequisite for deployment in Europe, and is scoped rather than merely intended.
Planned
Demographic performance reporting
Measuring whether accuracy differs across groups, and publishing it. Where a vendor supplies a tool used in hiring, this is increasingly the vendor's responsibility and not only the employer's.
06 — Boundaries

What this will never do

Not a backlog. Each was considered and rejected in writing, and each rejection is load-bearing — several are what keep the system outside the regulatory categories above.

Never
Emotion, attention or engagement inference
Inferring emotional state in workplace and education contexts has been prohibited under the EU AI Act since February 2025, with penalties reaching 7% of global turnover. It will not be built, and any monitoring feature is constrained by this line.
Never
One-to-many face search
Searching a face against a database is remote biometric identification. It is also what turns a verification tool into a surveillance tool. Verlinko compares one person only to their own earlier self.
Never
Automated rejection of a candidate
A failed check routes to a human. The system holds no mechanism to reject anyone, which is both the correct design and what keeps it an advisory tool rather than a decision-maker.
Never
Session recording
Creates exactly the retention liability the product exists to eliminate.
Never
Storing candidate names or contact details
Employers contact their own candidates. Verlinko never learns who they are.
Never
Selling or sharing biometric data
Templates exist to answer one question for one employer, and are deleted on schedule.
07 — Sequence

The order this
is being built.

No dates are published. This is an independent prototype rather than a funded roadmap, and a date on a public page ages badly.

Phase 0Stop the bleedingIn progress

Encryption switched on. Default platform permissions revoked. Legacy access paths closed. Paid infrastructure tiers so the service cannot pause. Secrets management.

Phase 1Identity and accessNext

Roles and permissions. An interviewer view that shows the session but not the trust signals. A company-admin surface so an organisation manages its own users. Rate limiting.

Phase 2Database-enforced isolationPlanned

The largest and most careful piece: moving tenant separation from application code into the database, table by table, with a full verification run after each. Highest risk, and not rushed.

Phase 3Key management and evidence integrityPlanned

Per-tenant keys. Audited break-glass access. Hash-chained audit records. Public-key receipts. Retention enforcement with proof of deletion.

Phase 4+What commercial readiness would requirePlanned

Single sign-on and directory sync. Resilience, monitoring and tested restores. EU region. SOC 2 observation window running in parallel from Phase 1 onward, because it is elapsed time rather than engineering time.

Peer review is genuinely welcome. Ask about the current state of any row above and you will get a straight answer, including the ones that have slipped. An honest gap examined is worth more than a claim that fails a second look — if you work in security, privacy or hiring technology and something here looks wrong, I would rather hear it.

Read the project story →