Skip to content
vreko

example passport · for recruiters and evaluators

Read one approved view in under a minute.

This is what a recipient sees after an operator approves a view for one purpose. Open a claim for Vreko's reading of the evidence, then inspect the evidence itself. Nothing here is a score.

Specimen · synthetic data. Not a real person, not a live Passport, and not produced by a certified production projection.

a 30–60 second read

  1. What is the actual claim?
  2. What evidence supports or limits it, and from which source?
  3. What was observed, what was declared, and what is unknown?
  4. What did the operator do, and what did an agent or team do?
  5. What single follow-up question would change your next step?
recipient view · approvedspecimen

Specimen operator

Platform engineer. Works with coding agents on most changes.

purpose
Evaluate demonstrated work for a platform-engineering role
shared with
one hiring reader
approved by the operator
2026-09-28 · expires 2026-10-28
supportedLed the migration of a billing service from scheduled jobs to a message queue.
vreko-derived

The evidence supports this. Repository history shows the operator authored the migration plan and most of the changes, and a reviewer other than the author approved the release. Agent-written changes are recorded in session receipts.

operator-provided

Declared by the operator. Wording corrected on 2026-09-26.

attribution · who did the work

operator · known  /  agent or team · partial

Operator authored the plan and directed the work. Some changes were agent-written and are recorded as the agent's.

what this view establishes

  • The operator led a reviewed migration that was released.

what it does not establish

  • Business impact.
  • That the design was the best option.
  • Sole personal implementation of every change.
Inspect evidence (3)
  • source recordTeam repositorysupports

    Repository history shows the migration plan and changes under the operator's account.

    platform record · not an independent evaluation · work by operator · observed 2026-09-27

  • source recordCode review recordsupports

    A reviewer other than the author approved the release change.

    independently observed · work by operator · observed 2026-09-27

  • source recordAgent session receiptscontext only

    Session receipts record which changes an agent wrote and which the operator wrote.

    self-reported · not independent · work by agent · observed 2026-09-27

partially supportedReduced failed billing runs after the migration.
vreko-derived

Part of this is supported. The rest is not. The tracker records fewer billing-failure tickets after the release. Nothing bound here separates the migration's effect from other changes made in the same period.

operator-provided

Declared by the operator.

attribution · who did the work

operator · unknown  /  agent or team · unknown

Not attributable from this view.

what this view establishes

  • Billing-failure tickets fell after the release.

what it does not establish

  • That the migration caused the drop.
  • The size of any effect.

what could resolve it A failure-rate measurement that isolates the migration from other changes.

Inspect evidence (1)
  • source recordIncident trackersupports

    Billing-failure tickets recorded before and after the release.

    platform record · not an independent evaluation · work by unknown · observed 2026-09-27

contestedHad the migration verified by someone other than the author before release.
vreko-derived

Evidence points both ways. Unresolved. An independent review supports it. An independent release audit goes against it. Both are kept visible; neither is collapsed into a verdict.

operator-provided

Declared by an agent in-session. The operator has not confirmed it.

attribution · who did the work

operator · unknown  /  agent or team · partial

Agent declared. Operator authority over the declaration is not established.

what this view establishes

  • That independent evidence points both ways and is unresolved.

what it does not establish

  • A verdict either way.
  • A confidence level.
Inspect evidence (2)
  • source recordCode review recordsupports

    A reviewer other than the author verified a release candidate before release.

    independently observed · work by team · observed 2026-09-12 · ◍ stale, not re-read within its window

  • source recordRelease audit recordcontrary

    The release audit records that the build that shipped was not the build the reviewer checked.

    independently observed · work by team · observed 2026-09-27

contradictedCompleted the cut-over with no customer-visible downtime.
vreko-derived

The bound evidence goes against this. The status page records a customer-visible outage during the cut-over window. The operator's dispute is shown beside the claim; a dispute does not change the state.

operator-provided

Declared by the operator. The operator has recorded a dispute (see corrections).

attribution · who did the work

operator · unknown  /  agent or team · unknown

Not attributable from this view.

what this view establishes

  • Bound evidence goes against the claim.

what it does not establish

  • Who or what caused the outage.
Inspect evidence (1)
  • source recordStatus page historycontrary

    A published outage overlaps the cut-over window.

    platform record · not an independent evaluation · work by unknown · observed 2026-09-27

unknownRuns production on-call for the billing service.
vreko-derived

Not enough evidence. Not a negative finding. No source in this view addresses on-call work, so the claim stays unknown.

operator-provided

Résumé line, declared by the operator and not verified.

attribution · who did the work

operator · unknown  /  agent or team · unknown

Declared by the operator. No source in this view addresses the proposition.

what this view establishes

Nothing yet.

what it does not establish

  • That the claim is false. Unknown is not a negative finding.

what could resolve it An on-call schedule or paging record from the service's incident system.

Inspect evidence (0)

No source in this view addresses this claim.

three kinds of material, always kept apart

source record
Recorded by the source system itself, such as a repository's history or a tracker's record.
vreko-derived
Vreko's reading of what the evidence establishes for this claim. It can change when the evidence does.
operator-provided
Declared, corrected or disputed by the operator. A declaration is not evidence that it is true.

Origin says where material on the page came from. It does not say who did the work: attribution (operator, agent, team or unknown) is shown separately, and neither changes a claim's state.

ask the passport

What Ask can and cannot answer.

Ask answers from this approved view: its claims, their states, their evidence, and what each does not establish.

It cannot see the operator's private Passport, evidence the operator excluded, or how much was excluded.

suggested questions · from what this view names

What did this person build?

This view shows one piece of work: the billing-service migration.

Each claim about it keeps its own state. Open any one for what it does and does not establish.

what this view establishes

  • A reviewed migration was released (team repository, code review record).

what it does not establish

  • Business impact.

Based only on the view approved for one hiring reader, to evaluate demonstrated work for a platform-engineering role.

What was their role in the billing-service migration?
supported

They authored the plan and directed the work. Some changes were agent-written.

Authorship of the migration is recorded under the operator's account; session receipts mark the agent-written changes as the agent's.

what this view establishes

  • The operator authored the migration plan and directed the work (team repository).
  • Some changes were written by an agent and are recorded as such (agent session receipts).
  • A reviewer other than the author approved the release (code review record).

what it does not establish

  • Sole personal implementation of every change.

Based only on the view approved for one hiring reader, to evaluate demonstrated work for a platform-engineering role.

Was AI involved in the billing-service migration?

Agent involvement is recorded for two claims: the migration (supported) and the pre-release verification (contested).

Where agent share is not recorded, this view does not say either way. Not recorded is not the same as not involved.

what this view establishes

  • Session receipts separate agent-written and operator-written changes.
  • The pre-release verification claim was declared by an agent.

what it does not establish

  • How much of each change the agent wrote.

Based only on the view approved for one hiring reader, to evaluate demonstrated work for a platform-engineering role.

What remains unknown in this view?
unknown

Unknown in this view: runs production on-call for the billing service.

Unknown is not a negative finding. What could resolve it, as approved in this view: an on-call schedule or paging record. Separately, one claim is contested and one is contradicted; each keeps its own evidence.

what this view establishes

Nothing yet.

what it does not establish

  • That the on-call claim is false.

Based only on the view approved for one hiring reader, to evaluate demonstrated work for a platform-engineering role.

a question this view cannot fully answer

asked Did they personally implement the whole billing-service migration?

unknown

This view does not establish that.

Unknown is not false. Leading the migration is narrower than implementing every part of it, and agent work stays the agent's. You may request additional evidence.

what this view establishes

  • The operator authored the migration plan and directed the work (team repository).
  • Some changes were written by an agent and are recorded as the agent's (agent session receipts).
  • A reviewer other than the author approved the release (code review record).

what it does not establish

  • Sole personal implementation of every part of the migration.

Based only on the view approved for one hiring reader, to evaluate demonstrated work for a platform-engineering role.

when the view cannot answer · alpha contract

Asking is not requesting. Only a submitted request reaches the operator.

  1. askThe recipient asks the viewAsk answers from the approved view only. An ordinary question is not passed to the operator as a request.
  2. insufficient viewThe view cannot answer“This view does not establish that.” Unknown is not a negative finding.
  3. submit requestThe recipient may submit one bounded requestAn explicit request names the exact question, the purpose and who is asking. Only a submitted request reaches the operator. Submitting it reveals nothing beyond the approved view and shares nothing new.
  4. operator decidesThe operator decidesStop, refuse, narrow, authorize a source, or provide evidence.
  5. separate approvalAnything new is approved separatelyIf what the recipient can see would change, it is prepared as a new version of the view. The operator previews exactly what changes and approves it separately. Only then does the recipient see it.

operator decisions

STOP
Closes the exchange. Nothing new is shared.
REFUSE
Declines the request. Nothing new is shared.
NARROW
Prepares a narrower answer. The recipient sees it only after a separate approval.
AUTHORIZE / PROVIDE
Connects a source or adds evidence. A changed view still needs a separate approval, and needing to gather evidence shares nothing by itself.

Neither stop nor refuse says anything about whether the claim is true. A request exists because the approved view was not enough, not because anything private was found.

Alpha contract, shown as a specimen. Not a live request interface.

Specimen exchanges, written to the Alpha's answer rules from this synthetic view.

Corrections and disputes

Recorded beside the original. A correction or dispute does not rewrite the source record, does not by itself change a claim's state, and cannot recall anything a recipient has already read or saved. A changed view needs a new approval.

  • operator-provided2026-09-26 · editOperator narrowed 'Designed and built the billing queue' to 'Led the migration'. The earlier wording stays in history; the source records are unchanged.
  • operator-provided2026-09-27 · disputeOperator disputes that the outage was customer-visible. The dispute is recorded beside the claim; the status-page record and the claim's state are unchanged.

Sources in this view

Each source is described by what it records and what that does not mean.

Team repository
Hosts the source and its history. Does not review or endorse the author.
Code review record
A reviewer other than the author approved changes. Review is not endorsement of the author.
Incident tracker
Records incidents and tickets. Does not attribute cause.
Agent session receipts
Records what the operator and agent did in a session. Not a reviewer.
Status page history
Records customer-visible outages as published by the team.
Release audit record
An audit by someone other than the author of which build shipped. Does not judge the work.

Want a Passport of your own work?

The private Alpha is a small, curated cohort. Applications are reviewed.

How the Alpha works →
Vreko · by Marcelle LabsEvery claim on this site is current, part of the Alpha under test, or not built, and says which. The example Passport is a synthetic specimen.
Example Passport · Vreko