LIVE MEASURED
Observed on a running system with recorded measurement artifacts.
How we know ATOMiK works today
ATOMiK proof is organized by evidence tier. Performance claims must be quoted only with their artifact, workload context, and caveat. Do not isolate the biggest number without the interpretation.
Public proof packet
The current proof stack is artifact-bound: a Zynq UI proof image, Linux userspace-to-FPGA validation, and a live-measured AX7020 workload matrix with wins, losses, and caveats. The next evidence gate is customer-representative Zynq workload validation.
Artifact map
The public site links to the evidence and benchmark page, hardware proof map, claims registry, and evidence labels.
Evidence labels
Claims are separated as live measured, hardware validated, software validated, formal proof, synthesis validated, build artifact, projected, conceptual, or roadmap.
Claim control
The registry records public-safe claims, artifacts, caveats, and overclaim risks for current public materials.
Hardware validated
ATOMiK Desk v0.39-K is a current prototype UI screenshot running on live Zynq hardware. It is not proof of power, thermal, uptime, or production maturity.
Hardware validated
The Linux userspace proof validates the path from user process through Linux, MMIO, Wishbone CSR bus, and FPGA accelerator for algebraic checks.
Live measured
The matrix shows ATOMiK can win in specific coalesced/batched scenarios and lose in others. Use it with the interpretation caveats.
Formal proof
Formal proof work is present in the repository. Public pages should avoid unaudited proof counts unless the count is verified across repo, site, and deck.
Synthesis validated
Synthesis and toolchain outputs are useful evidence but must not be blended with live-board measurements.
Roadmap / conceptual
Concept visuals explain product direction only. They are not proof of current commercial functionality.
Downloadable technical packet
These are public-safe proof digest files and machine-readable exports. They support diligence without turning the public homepage into a raw artifact dump.
Download
Nontechnical digest: what each artifact proves, what it does not prove, and safe language.
Download
Prevents blending v0.39-K UI proof, AX7020 matrix proof, Linux validation, SD boot, and formal proof.
Download
Compact workload-specific readout of the live-measured AX7020 matrix.
Download
One-page summary of Linux userspace-to-FPGA validation and boundaries.
Download
Machine-readable CSV export for technical review.
Download
Machine-readable summary and caveat file.
Download
Required caption for the v0.39-K hardware UI artifact.
Download
SHA-256 hashes for downloadable public proof artifacts.
Evidence labels
LIVE MEASURED
Observed on a running system with recorded measurement artifacts.
HARDWARE VALIDATED
Demonstrated on physical hardware without implying production readiness.
SOFTWARE VALIDATED
Shown in software prototype, simulation, local runtime, or formal work.
SYNTHESIS VALIDATED
Supported by toolchain output, separate from live-board measurements.
FORMAL PROOF
Directly audited formal statements only; do not use as workload, customer, or production proof.
BUILD ARTIFACT
Concrete local build output exists, but the full path is not promoted as live proof.
PROJECTED
A model or estimate. It must not be phrased as an observed result.
CONCEPTUAL
Explains direction or UX. It is not current functionality.
ROADMAP
Planned work that may change.
What each proof does and does not prove
HARDWARE_VALIDATED
What it supports: A current ATOMiK Desk prototype UI image was captured from live Zynq hardware.
What it does not support: It is not a customer workload benchmark and does not prove power, thermal, battery, uptime, footprint, or production maturity outcomes.
LIVE_MEASURED
What it supports: A recorded board run produced software, direct hardware, batched, and profiled results on the AX7020 path.
What it does not support: It does not prove ATOMiK is always faster. The interpretation shows wins in specific coalesced/batched scenarios and losses in others.
LIVE_MEASURED
What it supports: The honest readout: naive hardware access can lose, batching can help modestly, and coalescing can drive the meaningful win when the workload fits.
What it does not support: It does not validate SYNC bytes-avoided behavior in the current matrix because the document records that limitation.
HARDWARE_VALIDATED
What it supports: ATOMiK algebraic checks passed through a Linux userspace to kernel/MMIO/Wishbone/FPGA path.
What it does not support: It does not by itself prove production readiness, battery improvement, or thermal improvement.
SYNTHESIS_VALIDATED
What it supports: Toolchain and hardware/synthesis characterization exists for parallel accumulator configurations.
What it does not support: Synthesis ceilings must not be quoted as live-board performance unless a matching board-run artifact exists.
CLAIM CONTROL
What it supports: Public-safe claims, labels, artifacts, caveats, and notes are tracked in one registry.
What it does not support: The registry is a control surface, not a substitute for the linked raw artifacts.
FORMAL_PROOF
What it supports: Formal proof work is present in the repository and can be reviewed in technical diligence where a directly audited statement is identified.
What it does not support: Public pages should not repeat unaudited proof counts unless the count is verified across repo, site, and deck.
Performance warning
The current interpretation says ATOMiK can win when batching and coalescing match the workload, and can lose when naive hardware access or high unique-region ratios dominate. The honest claim is workload-specific: ATOMiK is strongest where state movement, repeated scans, full-state sync, replay, or reconstruction dominate the cost.
- Do not say ATOMiK is always faster.
- Do not claim proven heat, battery, water, or footprint improvements without artifact-backed measurement.
- Do not treat concept visuals or synthesis ceilings as live performance proof.
Bring one workload, one baseline, and one constraint. ATOMiK will map the evidence tier required before making any public or diligence claim.
Request Evaluation