AN INDEPENDENT PROOF OF CONCEPTNot affiliated with GameStop or eBay ↗
Home/White Papers/Employee App Architecture
RESEARCH & ARCHITECTURE / ORIGINAL V0.1

Employee App Architecture

Foundational October 2026 paper · Full web edition

Download the PDF ↓

Foundational document. This is an edited v0.1 edition, with identifying author details and selected passages removed for privacy and clarity. Branding, application flows, and technical implementation have evolved since publication. Proposed partnerships, policy decisions, and integrations are future-state ideas—not announced products or live financial services.

THE TRUST TERMINAL

Employee application / technical design

IMPLEMENTATION SPECIFICATION / v0.1 / 11 OCTOBER 2026

The customer sees a trade window. The operator sees the evidence and controls that decide whether a contribution can actually proceed. This app must make the correct action easy without making an unsupported approval easy.

What ships in this kit

A connected employee surface with a two-item intake queue, expected-item reference, evidence-linked checklists, optional local photo preview, sample evidence actions, store-intake decisions, a separate simulated specialist role, discrepancy handling, a passport/event view and post-settlement pickup/return intake.

The customer app updates from the same session. In local server mode, different windows share changes through HTTP commands and SSE. A single-file demo can switch between customer and employee roles within one page. There is no real staff login or production authorization boundary.

Supported demo workflows

ItemStore responsibilityApproval route
Xbox One controllerIdentify, document condition and record functional-check evidenceStore completion makes the demo contribution eligible
Vintage JordansCompare declared item, gather condition/label evidence, record custody/seal stepIntake sends to specialist review; store intake alone is not authentication
Vaulted CharizardDisplay a fictional linked-vault offerNo new store inspection in this fixture
Graded underwearInspect fictional listing and policy explanationUnsupported route; no authenticated value

The seeded sneakers and controller are teaching fixtures, not approved real authentication manuals. The app does not claim to identify counterfeits, verify an identity document, decode a real serial registry or authenticate a PSA slab.

Operating principle: the employee can document an observation; the system must separately decide whether the evidence, authority and procedure support the next transition.

01 / Intake flow and decision gates

Complete the evidence, not merely the checklist.

The employee opens the expected transaction and chooses an item. In a deployed system an intake QR code would resolve an authorized session; the demo displays a deterministic intake code rather than implementing a secure QR handoff or a camera scanner.

Step-by-step behavior

StepWorking behaviorProduction extension
Identify expected itemShow fixture identity and declared conditionBind trade, item, customer and store authorization
Capture required evidenceAttach a sample or a bounded local image reference and noteSecure upload; acquisition metadata; quality controls
Finish intakeDisabled/rejected until all mandatory references existValidate evidence type, quality, completeness and consent
Route categoryController verifies; Jordans enter reviewVersioned category/variant policy determines permitted reviewer
Specialist actionSeparate demo role approves review-state sneakersAuthenticated independent reviewer with appropriate scope
Flag discrepancyRecord bounded reason; block value; reset approvalsCase management, notifications and proportionate restriction
Pickup / returnRecord post-settlement handoff or return intakeIdentity/authorization and inventory reconciliation

Every evidence command identifies the asset and procedure step. Evidence cannot be edited after intake unless the inspection is reopened. Reopening clears evidence and resets economic approvals. A store employee cannot approve the specialist-only step through the domain contract, although the prototype deliberately lets a presenter switch demo roles.

Observation is not an accusation

Use precise issue labels: variant mismatch, condition discrepancy, missing evidence, unresolved authenticity concern, custody/seal exception or functional failure. “Counterfeit” should not be the default explanation for any mismatch. The sample flag modal asks the operator to explain what was observed.

A changed condition may require a new price and fresh customer acceptance, not a one-sided discount. The current fixture takes the conservative path: failed contribution becomes zero and settlement is blocked until the route is resolved or removed. It does not automatically negotiate a revised price.

Preserve a useful escape hatch

Operators need pause, escalation, refusal-to-open and “procedure does not match item” options in production. The customer must retain a clear account of what has been received and how it can be recovered while review is pending. The prototype models flag/reopen rather than a complete service-desk workflow.

02 / AI-assisted procedure system

Retrieve and explain. Do not improvise authority.

The envisioned assistant chooses from a curated, versioned procedure library. It can suggest a candidate model, ask for a clearer photograph, compare declared and received condition, and explain a required step. It cannot create new approval criteria from an unsourced web answer or turn a model confidence score into an authentication certificate.

Proposed procedure record

FieldPurpose
procedureId / version / statusStable identity; reviewed version; active or withdrawn
category / variants / exclusionsExact applicability and cases requiring escalation
requiredRole / tools / consentWho may perform it, with what equipment and authorization
stepsOrdered observations and required evidence types
referenceSetLicensed or approved sources and specialist-reviewed examples
decisionRulesExplicit pass/review/fail conditions; never model-generated at runtime
escalationRouteResponsible specialist queue and service expectation
approvedBy / effectiveAtAccountable approver and change control

A cartridge-opening procedure, for example, must specify supported variants, required tools, permission and handling limits. It must not simply tell an employee to unscrew an expensive item because the internet contains a teardown. The shipped demo avoids disassembly instructions entirely.

Suggested processing pipeline

Treat customer text, image metadata, retrieved pages and OCR output as untrusted input. Candidate identification narrows the search; a policy service selects eligible approved procedures; a model explains their steps; a human gathers evidence; a deterministic gate and authorized reviewer decide the outcome.

Quarantine conflicting or incomplete references. When no approved procedure fits, return “specialist review required” rather than a confident checklist. Show the exact procedure version and distinguish submitted claims from verified observations.

Evaluation before use

Build specialist-labeled evaluations across authentic variants, condition ranges, counterfeit families, difficult photographs and out-of-distribution items. Measure false acceptance, false rejection, abstention and escalation by category, not only one aggregate accuracy number. Assess both model errors and employee interpretations of model output.

Review confirmed errors before adding them to training or procedure data. Customer claims, successful sales and employee approvals are not automatically reliable labels. No live model or learning loop is included in this prototype; the visible checklist and explanations are deterministic fixtures.

03 / Evidence, custody and the Asset Passport

An auditable claim about an item is not the item itself.

The proposed passport references the item's identity, condition evidence, inspection attestations, current custody and relevant ownership or redemption rights. These are separate dimensions. “Store received” must not be presented as “specialist authenticated.” An authenticated item outside controlled custody must not retain the same transfer assurances without a re-entry decision.

Custody event contract

A production event should identify the asset, transaction, package/seal reference, sending and receiving parties, location class, timestamp source, procedure version, relevant evidence digests, actor/service signature and exception state. Signatures need managed keys and revocation; a signed false statement remains a false statement.

At handoff, reconcile the expected item and package against the observed one. Use item-specific evidence, identifiers where available, tamper-evident packaging, recorded discrepancies and risk-based reinspection. Weight or a seal is supporting evidence, not conclusive authentication. Separate shipping status from custody acceptance.

The passport's audiences

AudienceAppropriate view
Buyer / future ownerRelevant item description, disclosed condition, assurance status and permissible history
Store operatorAssigned intake, approved procedure and minimum customer verification context
SpecialistCategory evidence and review context; no unrelated account portfolio
Claims / complianceScoped case evidence and custody history under access controls
Public token observerMinimal reference or commitment, not private identity or full inspection photographs

Where the NFT belongs

An optional token can reference signed attestations or a hash commitment to the passport. Minting, transfer and redemption must follow an approved relationship between the token, the custodian and the physical asset. Duplicate-token prevention, lost keys, stolen goods, legal orders, disputes and redemption require operational rules.

The working app says no token is minted. Its event list is an unsigned, bounded demo log, not an immutable blockchain, tamper-proof audit trail or legal title registry. Sample custody strings do not prove any real package was received.

For a future vaulted transfer, the goods may remain physically stationary while the authorized entitlement changes. For a return or re-entry from private possession, establish a new custody and condition review. The old passport is evidence to compare against, not a free pass.

04 / Internal security and operations

Trust the role only after authenticating the actor.

Production requires staff identity, device enrollment, scoped authorization, store assignment and appropriate authentication strength. Separate intake, specialist approval, valuation changes, payout actions and case resolution. High-risk categories may require independent dual review; policies must specify when rather than relying on a second checkbox.

The demo validates role labels at the domain boundary but accepts those labels from the client. It therefore illustrates separation of duties without enforcing real identity separation. Do not expose the local server publicly or use it for real custody records.

Evidence handling

The local photo picker allows JPEG, PNG and WebP up to 2 MB. A temporary preview exists in browser memory; only a bounded filename/reference and note enter the shared record. The actual photograph is not uploaded, durable, authenticated or compared by AI. Sample-evidence buttons are explicitly a presentation feature and must not appear as an approval shortcut in production.

A production system should issue short-lived upload capabilities, validate bytes and metadata, secure stored evidence, bind uploads to the right step, retain originals where policy permits, detect obvious duplicate submissions, and audit access. Offline capture needs protected local storage and explicit upload status. An offline device should not finalize eligibility merely because it has checked every box.

Operational controls worth measuring

Evidence completeness and quality, unreasonably fast approvals, repeated reused evidence, category-specific dispute rates, specialist reversals, custody exceptions, stock discrepancies and abandoned inspections. These signals should prompt review; they are not automatic proof of employee misconduct.

Avoid throughput incentives that reward skipping required work. Route unsupported categories to specialists instead of extending every store's checklist indefinitely. A ten-dollar item and a rare collectible do not justify identical labor, handling and assurance promises.

Recovery and privacy

A failed upload should preserve an unsent draft without claiming completion. A stale session should refresh before mutation. A revoked procedure should block new approvals and identify affected in-progress work. A compromised staff account should be suspendable without erasing its audit history.

Store only information necessary for the operation. Define retention, access, deletion and case-preservation policies before collecting identity documents or customer photos. The customer's broader digital asset holdings are not information every employee needs to see.

05 / Exceptions, tests and launch gates

Make the safe failure as convincing as the happy path.

Demonstration acceptance tests

ScenarioRequired result
Missing evidence stepFinish intake rejected; no eligible physical contribution
Sneakers intake completeStatus becomes review, not authenticated
Employee attempts specialist approvalDomain role check rejects it
Specialist approves review stateEligibility updates; customer sees new status
Operator flags condition mismatchContribution blocked, approvals reset, reason visible
Customer changes basket after acceptanceBoth participants must accept the new revision
Duplicate settlement commandNo second settlement
Return versus voluntary buybackDistinct request state; original settlement unchanged
Two clients update old stateServer detects stale version rather than overwriting silently

The delivered suite passes 28 Node tests and nine browser scenarios. The walkthrough includes five sneaker evidence steps and three controller steps; HTTP/SSE is tested separately. See browser-test-results.json. These are mocked workflow tests, not proof of real authentication, secure evidence custody, native device behavior or payment-provider correctness.

Pilot sequence

Start with a fabricated-asset usability study: do operators distinguish intake from authentication, and do customers understand conditional value? Next add one category, a specialist sandbox, authenticated roles, signed decisions and durable evidence/custody storage. Exercise missing procedures, disputed condition, damaged packaging, offline capture and partial fulfillment.

A real pilot additionally requires explicit liability, insurance, customer recourse and support ownership. Expand categories only after demonstrating safe and economical operation.

References and boundary

The concept extends the public GameStop trade/collecting story and eBay's category-specific authentication model; it is not documentation of an existing combined employee platform. S3: GameStop trade-in. S7: eBay sneaker Authenticity Guarantee. S8: eBay Money Back Guarantee. Full primary-source references and the public-research boundary appear in research/sources.md.

Buck's closing note: Legendary inventory. Documented provenance. No mystery checkboxes.