TRAKON Product Whitepaper

Native RFID Asset Tracking, Inventory Counting & Exit Protection

Asset Basic + Count Basic + Guard Basic: Three Free Modules

July 2026 · ACCUZ® Industries

Scope statement: This whitepaper covers the three free modules that TRAKON currently offers, namely Asset Basic (asset tracking), Count Basic (inventory counting), and Guard Basic (exit protection and anti-theft), along with the platform, hardware, security, and multilingual capabilities that support them. Other modules such as warehouse management (WMS) and the future paid Plus tiers are out of scope for this edition. A new edition of the whitepaper will be published for each module once it is officially released.

1. Summary

TRAKON is a native RFID software platform from ACCUZ® Industries. It uses EPC Gen2 UHF passive RFID technology and is delivered as a multi-tenant cloud SaaS. It is built for real-world operations: it lets organizations read tags in bulk within seconds, with no item-by-item handling and no line-of-sight aiming, so they always know who borrowed what, where it is, what is missing, when it needs calibration, and whether anything has been carried out the door without authorization.

The platform currently offers three free modules:

• Asset Basic: RFID asset and tool tracking, centered on checkout/return accountability and calibration-due management.
• Count Basic: RFID inventory counting, centered on cycle counts, reconciling overages and shortages, and locating missing items.
• Guard Basic: RFID exit protection and anti-theft, centered on arming checkpoints, real-time alerts for unauthorized egress, and egress approvals.

The business model is simple and transparent: the Basic software is free with no subscription, and customers pay only for RFID readers and tags. It is usable the day the hardware arrives, login accounts are delivered with the hardware, and no integration project is required. The platform offers four interface languages: Chinese, English, Japanese, and Korean.

All three modules run on the same enterprise-grade multi-tenant SaaS, with a single sign-on launcher, RS256 JWT authentication, per-tenant data isolation, an append-only audit log, and HTTPS transport encryption.

2. The Problem to Solve

Most organizations still manage assets and inventory today with manual ledgers, item-by-item barcode scanning, and spreadsheets, which creates a series of long-standing pain points:

• Can't find things, or finding is slow: tools, instruments, and stock are scattered everywhere, and people rely on memory to locate them.
• Counting is time-consuming and disruptive: a full count can take hours to days and often requires halting operations.
• Data lags behind: ledgers do not match the physical reality, and decisions are based on outdated numbers.
• Losses go unrecorded: items borrowed but not returned, damaged, or lost lack a traceable chain of accountability.
• Assets are carried out without anyone noticing: valuable tools, samples, and equipment are carried out the door without authorization and are often discovered only after the fact, with no automatic interception or trail at the exit.
• Calibration is out of control: critical measuring instruments go past due with no one watching, and operating with faulty equipment creates compliance and safety risks.

Barcodes are just "digitized manual data entry": you still have to handle each item, aim, and scan one at a time. RFID, especially UHF passive, is fundamentally different: it can read hundreds of tags in seconds, requires no line-of-sight aiming, and completes a count as people simply walk past. TRAKON turns this read capability directly into usable asset, counting, and protection workflows.

3. What TRAKON Is

• Native RFID, not "a barcode tool with RFID bolted on": the platform was built for EPC Gen2 UHF passive RFID. Tag binding, bulk reading, locating items, and exit detection are first-class capabilities, not add-on connectors or glue code.
• Multi-tenant cloud SaaS: each customer is an independent tenant, with data isolated from one another. Log in and start using it.
• One platform, multiple modules: it currently offers three free Basic modules, with more modules available as the business grows.
• Free software, pay for hardware: the Basic modules are free with no subscription; you purchase only readers and tags.

4. Platform Architecture

TRAKON consists of a SaaS platform (the control plane) and several module applications (the business plane).

Multi-tenant isolation

• Every record in the platform database is isolated by tenant_id; a user is unique within a tenant (tenant + email).
• tenant.code is an immutable, unique identity across stacks.
• Every request re-verifies the tenant carried in the JWT against the database, preventing drift between the token and the database (defense in depth).
• Cross-tenant queries are not allowed by design.

Unified Portal and Single Sign-On (SSO)

• After logging in to the portal (a Vue 3 single-page application), the customer sees a module launcher that lists only the modules the tenant has enabled and that are in a valid state.
• When clicking into a module, the platform issues a single-use RS256 bridge token valid for 120 seconds, embedded in the module launch link; the module subdomain uses it to complete automatic login, so the customer does not have to log in a second time.
• Three checks are performed before issuance: the module exists, the tenant holds a valid entitlement, and the module address is configured.

Module Entitlement and Provisioning

• Each "tenant + module" pair corresponds to one entitlement record (whether enabled, status, optional validity period, optional plan). A newly created tenant is not entitled automatically by default; the operator enables it as needed.
• Devices (readers / handhelds) are onboarded via a single-use, time-limited provisioning code: the code is stored only as a SHA-256 hash, and redemption is an atomic operation. On successful provisioning, the platform pushes the tenant and user roster to the corresponding Basic module stack (and rolls back if the push fails, leaving no half-provisioned devices).

Technology Stack and Deployment Form

• Frontend in Vue 3, backend in FastAPI, database in PostgreSQL, with Redis for caching and rate limiting.
• Containerized deployment; each module is an independent stack on its own subdomain, with HTTPS/TLS terminated by nginx.

5. Asset Basic (Asset Tracking) in Detail

Positioning: full-lifecycle accountability for assets and tools. In one sentence: who took what, where it is, and when it needs calibration.

Asset Ledger Each asset record includes: asset number (unique within the tenant), name, category, status, location, current holder and checkout time, calibration status, department, photo, extensible custom fields (JSON), the time it was last read, and more.

RFID/EPC Tag Binding Bind or rebind a UHF EPC tag to an asset; the EPC is normalized before storage and enforced as unique within the tenant. When an unknown tag is scanned at a workstation, it can be registered on the spot as a new asset (create-as-you-scan).

Print and Bind (Label + Read EPC) A two-step flow: first generate a tracking number and render a ZPL label template, then collect the print and EPC-read results and bind them idempotently. The whole process has five auditable outcomes (initiated, succeeded, printed but no EPC, failed, and succeeded but binding failed), which makes troubleshooting and reconciliation easier.

Bulk Import Supports bulk asset import via CSV. The frontend offers a downloadable template (with a UTF-8 BOM and the customer's real category names as sample rows). Locations can be resolved by full hierarchical path (such as "Building A > Floor 2 > Zone C") or by location ID, with each row validated and error rows returned.

Asset Status Lifecycle Six statuses: available, checked out, damaged, missing, lost, and retired; with enforced transition rules (a checked-out asset can only move to damaged/missing/lost; the holder information is cleared when retired, set back to available, or marked lost).

Checkout, Return, and Return on Behalf of Another An immutable transaction log: checkout (sets holder and checkout time), return (clears the holder), and return on behalf of another (records who it was returned for and corrects ownership when the system has already returned it automatically).

Report Damaged, Report Missing, Report Lost Report damaged (set to damaged + severity + description), report lost (set to lost, a terminal state), and report missing (set to missing, retaining the holder for supervisor review). Each one logs a transaction and triggers the corresponding alert.

Self-Service Workstation (Kiosk) A standalone full-screen self-service interface: a user identifies themselves by scanning their RFID badge (real-time scanning over WebSocket) or entering a PIN, then scans assets directly to complete checkout and return, with no portal login required. The workstation is locked to its tenant by device code.

Live Board An auto-refreshing list of current checkouts: asset, holder, checkout duration, overdue tiers (default 7-day warning, 30-day severe, both configurable), and calibration status; overdue items are automatically pinned to the top.

Calibration Lifecycle For each asset, record the calibration due date, calibration interval, and last calibration time, and compute the status (valid / due soon / overdue / not applicable). You can log calibration events (calibrated by, next due date, certificate link, notes) and view history; the dashboard and reports provide overdue and due-soon lists (default 14-day due-soon window). A policy option applies at checkout: for assets with overdue calibration, block or warn only (no blocking by default).

Dashboard and Reports The dashboard provides statistic cards (total assets, available, on loan, overdue, calibration due, needs attention), an area overview (asset status by building/floor/zone), a calibration outlook, a needs-attention list, and a quota usage card. Reports cover inventory overview, asset coverage (assets never read are flagged in red), asset utilization (checkout count, average duration, idle days), user activity (including all registered users with zero activity), calibration due, and more; every report page and the transaction log can be exported to CSV (generated client-side, with a BOM, and Excel-friendly).

Search and Observability The asset list supports filtering by status, category, department, location, calibration status, holder, and tag type, plus full-text search across number/name/EPC/holder and multi-field sorting. Operations such as checkout/return, report damaged/missing, and calibration emit events (checked out / returned / damaged / lost / missing) that the alerting engine can subscribe to.

6. Count Basic (Inventory Counting) in Detail

Positioning: complete a full-site count in minutes, knowing what is on the shelf, what is missing, and where to find it.

Count Basic shares the same asset ledger and tag-binding capabilities as Asset Basic, and on top of that provides counting workflows:

Spot Check Generate an "expected list" by location (including its sub-locations) or for all assets, and dispatch a temporary task package to a handheld; the handheld uploads the scanned EPCs (automatically de-duplicated); on completion, it compares the scan results against the expected list and sorts them into three categories: confirmed (on the list and scanned), missing (should be present but not scanned), and extra (scanned but not on the list). Task statuses: pending → in progress → completed/cancelled.

Follow-up You can generate a follow-up task directly from the "missing items" of a completed count; the follow-up snapshots this set of expected assets, so they remain tracked even if their locations change later.

Locating Missing Assets Supports locating a single asset as well as locating missing items within a count: it issues a time-limited temporary task and returns signal strength (RSSI) to guide a "hot/cold" search; if the tag is an LED-capable model, the LED can also light up to assist the search.

Locate History and Counting Reports Provides a read-only locate history (drawn from the audit log: time, action, result, source, signal strength). Reports cover count history (including coverage %), asset coverage, and locate history; the dashboard provides a counting overview widget.

7. Guard Basic (Exit Protection and Anti-Theft) in Detail

Positioning: keep protected assets from being carried out of the site without authorization. Install an RFID reader at the exit, and a protected asset that passes through without approval triggers a local audible/visual alarm and a real-time alert.

Guard Basic shares the same asset ledger and tag-binding capabilities as Asset/Count (register assets, bind EPCs), and on top of that provides exit-protection workflows:

Protection by Default Once an asset is entered and its tag is bound, it is protected from that moment on, with no separate "protection switch." Any protected asset that passes through an armed checkpoint without approval triggers an alert. The risk level (normal / high / severe) determines the severity of the alert that asset raises.

Checkpoint Associate an existing location with an anti-theft reader and give it a name (such as EXIT or Front Door). The reader ID can be chosen from readers the system has "observed" scanning, or its broadcast ID can be entered manually. Once saved, the checkpoint is Armed; it can be edited, deactivated, or deleted. One door or gate corresponds to one reader.

Live Alerts A real-time monitoring screen that lists unauthorized egress events one by one: severity (taken from the asset risk level), type, asset, checkpoint, EPC, status, read count, and last-read time. You can filter by open/closed, severity, area, and rule, and toggle sound on/off. Each alert offers five actions: view details, Acknowledge (meaning "I am handling it," while the alert stays open), Silence reader, Resolve (a real event has been dealt with), and Dismiss (a false positive, with a mandatory reason that feeds rule tuning).

Silence reader Temporarily silence a reader's hardware alarm for 5 minutes (without closing the alert), for on-site handling; a banner shows a countdown, and it can be extended by 5 minutes or lifted immediately. After it is lifted, existing open alerts no longer re-trigger the alarm; normal alarming resumes only on the next new tag read.

Egress Approval Let a given asset leave legitimately for a period of time (demonstration, repair, external loan): select the asset, set the valid start and end times (default 4 hours from now), and a mandatory reason. While the approval is in effect, the asset passes through checkpoints silently and raises no alert; approvals fall into three categories: active, expired, and cancelled. A silent pass-through is still recorded in the audit trail.

Alert History A review list of closed alerts (resolved + dismissed): first read, last read, severity, status, type, asset, and read count; it can be filtered by status, severity, area, and rule, and exported to CSV.

Audit Trail An immutable, complete operation log: time, operator, action, object, and metadata. It records events such as alerts being silenced, hardware alarms being issued, hardware alarms being suppressed by silencing, egress approvals being created, approved assets passing through silently, and silencing being lifted; it can be filtered by object type, action, and date range, or searched by reader_id / EPC / id, and exported to CSV.

Dashboard A single-screen overview: a Live Alerts snapshot, the risk posture (number of unhandled alerts, plus the counts of severe, high-risk, and normal assets), assets ranked by alert count, an alert activity chart, and a recent activity feed linking to the Audit Trail.

Alarm Semantics The alarm is latching: once triggered, it persists until an operator silences it or resolves/dismisses the alert. The decision and relay action are decided centrally by the backend (whether the checkpoint is armed, whether the asset is protected, and whether a valid egress approval exists); the reader only executes the local relay and buzzer actions.

8. The Relationship Between the Three Modules: Same Source Asset Model, Each With Its Own Role

Asset Basic and Count Basic are two editions of the same asset codebase; the edition is selected by an environment variable at deployment time, and the backend code is byte-for-byte identical across the two distribution packages. Guard Basic is an independent module running on the same platform, reusing the same asset ledger and tag binding, sharing the platform's multi-tenant, single sign-on, authentication, audit, and hardware/Bridge capabilities, and focused on exit protection.

All three are built on the same "asset + tag" foundation: first register an asset and bind an EPC, after which Asset handles checkout/return and calibration, Count handles counting and finding items, and Guard handles exit protection and anti-theft.

For Asset and Count, four feature groups are always on: the asset ledger (records + tag binding + categories + print-and-bind + on-the-spot registration), the dashboard, reports, and settings. The differences lie in three feature groups:

For a feature group that is off, the backend returns 403 and the frontend hides the corresponding entry points and routes. Guard Basic, as an independent module, does not use the Asset/Count edition switches; instead it provides its own set of protection features (Checkpoints, Live Alerts, Egress Approvals, Alert History, Audit Trail, Dashboard) that operate on the same asset entity. In short: Asset leans toward "accountability and calibration for assets/tools," Count leans toward "inventory counting and finding items," and Guard leans toward "exit protection and anti-theft."

9. Hardware and TRAKON Bridge

• Tags: EPC Gen2 UHF passive RFID tags. They can be read in bulk within seconds, with no line-of-sight aiming required.
• AZD-R1: a USB desktop reader, used for binding tags and short-range reading; plug-and-play, usable as soon as it is connected to a Windows PC running TRAKON Bridge, and it also supports Bluetooth (BLE).
• AZH-P1: an Android handheld reader, used for long-range bulk reading on the move, suited to counting and inspection rounds.
• AZ-T1C/G2: a ceiling-mounted anti-theft reader, installed above a doorway or gate to guard the exit, with a built-in buzzer and a red/green light bar and a read range of up to 20 m; it lets Guard Basic detect unauthorized egress of protected assets and is connected via TRAKON Bridge.
• TRAKON Bridge: a Windows desktop gateway program that connects to the local reader and exposes a command channel over WebSocket (start/stop/single scan, query status, set power, beep, scan interval) and broadcasts scan results. It connects only to the local reader and requires no hardware address configuration. A Bridge connects to one reader at a time, and you choose the reader in its setup. To switch to the other reader, reopen the setup and reconnect.
• The self-service workstation reads through the locally connected reader via Bridge.

Hardware Specifications (Datasheet Summary)

The above is a datasheet summary; see the corresponding product pages for full specifications.

10. Security and Multi-Tenant Isolation

• Authentication: RS256 JWT (access token 30 minutes, refresh token 7 days). Login is by "tenant code + email + password," with credentials validated within the tenant scope (no cross-tenant email lookup); any failure returns a uniform 401 that does not reveal whether the account exists.
• Passwords and PINs: stored uniformly as bcrypt hashes (12 rounds), never in plaintext.
• Multi-tenant isolation: every record is isolated by tenant, and cross-tenant queries are not allowed. Workstation identification (badge/PIN) is locked to its tenant by device code, so that different tenants using the same PIN/badge do not misidentify one another; PINs and badges are unique within a tenant, and if multiple matches are found, identification is rejected (to prevent a checkout/return being recorded against the wrong person).
• Rate limiting: Redis-based fixed-window rate limiting (login by account and IP, bridge, device redemption, key rotation, and so on); exceeding the limit returns 429 with a Retry-After header.
• Audit: the audit log is append-only; the runtime database role has only INSERT permission on audit tables (cannot modify, cannot delete), and a startup self-check verifies this posture; emails are stored as SHA-256 hashes to protect privacy while remaining correlatable; records are never deleted.
• Transport encryption: HTTPS/TLS is terminated by nginx (wildcard certificate), and the API is accessed same-origin through the reverse proxy.

11. Multilingual Support

The platform and the three Basic applications share the same internationalization architecture, providing four interface languages: Chinese, English, Japanese, and Korean. The language switcher at the top toggles instantly, the choice is remembered, and the default fallback is English.

12. Business Model

• The Basic software is free with no subscription; customers pay only for RFID readers and tags (tags are quoted by size and quantity).
• Free-tier allowance (official pricing): each customer includes 200 assets and 3 users; the specific quotas can be adjusted by the operator per contract.
• Ready to use immediately: plug in the reader, log in, and start tracking; login accounts are delivered with the hardware, and no integration project is required.
• Customizable: the RFID software can be customized around the customer's real-world processes.
• Future: a paid Plus tier will be offered once a customer outgrows the free tier (it is not yet live).

13. Onboarding and Deployment

• Cloud SaaS; each module is an independent stack on its own subdomain, served over HTTPS.
• After logging in to the portal, customers enter Asset Basic, Count Basic, or Guard Basic with one click via the module launcher (single sign-on, no second login required).
• Devices are onboarded with a single-use provisioning code and are automatically bound to their tenant.

14. Versions and Roadmap

• This whitepaper covers TRAKON's three current free modules: Asset Basic, Count Basic, and Guard Basic (July 2026).
• As new modules are released, a corresponding new edition of the whitepaper will be published.
• Some of the platform's administrative interfaces and workflows are still being refined.

Appendix A: Capability Quick Reference

Appendix B: Glossary

• RFID: Radio-Frequency Identification. UHF: Ultra-High Frequency. EPC Gen2 UHF passive tag: the tag type used by this platform, requiring no battery, no line of sight, and readable in bulk.
• Tenant: a customer organization, with data isolated from one another.
• SSO single sign-on / bridge token: a single-use, short-lived token issued by the portal that lets customers enter a module from the portal without logging in a second time.
• Spot Check: one RFID count that produces "confirmed/missing/extra."
• Calibration: the periodic verification and due-date management of measuring instruments.
• Workstation/Kiosk: a login-free self-service checkout/return terminal.
• Checkpoint: a monitored door or gate, associated with a location and a reader; once Armed, it intercepts unauthorized egress.
• Egress Approval: lets a given asset pass through a checkpoint legitimately and silently within a set time window.
• Live Alert: an unauthorized egress event that can be acknowledged, silenced, resolved, or dismissed.
• Silence: temporarily silence a reader's hardware alarm without closing the alert itself.

The content of this whitepaper is based on the actual product capabilities of TRAKON. Items such as the "free-tier allowance" reflect official pricing terms; the specific contract terms are subject to the formal quotation.