What a Kalstor OEM flash-storage buyer receives: the evidence pack

An OEM storage buyer does not need another promise that a card or SSD is “stable.” The buyer needs a record that answers six questions: what application was described, what configuration was proposed, which physical samples were tested, how they were tested, what passed or remained open, and what a repeat order must match.

That record is the evidence pack in a Kalstor project. It is not one universal certificate and it is not automatically identical for microSD, SSD, USB modules, eMMC or UFS. It is a controlled set of project records whose scope is agreed before volume approval [1][2]. Production and manufacturing tests are performed by the relevant source partner; Kalstor's responsibility is to connect buyer requirements, supplied configuration, reviewable evidence and commercial control without presenting an unsupported capability as fact.

The evidence pack is a decision record, not a marketing folder

A folder full of datasheets can still leave the central question unanswered: did the approved sample and the ordered product have the same relevant configuration? A useful pack is organized around a decision chain:

application requirement
-> proposed configuration
-> identified samples
-> controlled test and raw result
-> exception review
-> approval boundary
-> incoming-lot comparison
-> change or RMA record

Each arrow matters. A supplier datasheet can describe a rated range, but it does not prove behavior in the buyer's host. A buyer benchmark can measure one sample, but it does not prove what will ship later unless the approved configuration is identified. A certificate can support a quality-system or material-compliance statement, but it does not replace product-level endurance, compatibility or data-integrity evidence.

Kalstor therefore separates four evidence classes:

Record 1: the application brief

The pack starts with buyer inputs, not a preselected memory label. At minimum, the brief records:

Blank fields are visible. If the customer gives “4K camera, 256GB” but no bitrate, stream count, duty cycle or temperature, Kalstor can identify the missing inputs but cannot honestly calculate retention or endurance.

Worked requirement example

Consider a recorder writing four streams at a measured aggregate 32 Mbit/s. The decimal host-write calculation is:

Daily host writes = 32 Mbit/s × 10.8 = 345.6GB/day
Annual host writes = 345.6 × 365 ÷ 1,000 = 126.1TB/year
Five-year host writes = 630.7TB
Daily writes relative to 256GB = 345.6 ÷ 256 = 1.35 full-card equivalents/day

These numbers do not rate a Kalstor card or SSD. They define the workload that a proposed configuration must address. The same recorder may also require a minimum retention window, a peak-write margin, wraparound testing and controlled power interruption. Resolution alone cannot supply those values.

Record 2: the proposed-configuration sheet

The next record describes what the sample is supposed to be. Depending on product and disclosure scope, it may include:

• Kalstor commercial part number and document revision;
• form factor, interface, capacity and package dimensions;
• reported model, CID/CSD, firmware or NVMe/SATA identity fields;
• controller and NAND scope when available and agreed;
• speed, endurance and temperature ratings tied to their source document;
• label, packaging, preload or provisioning requirements;
• sample quantity, quote validity, lead time and MOQ;
• fixed fields, permitted equivalence and fields still awaiting confirmation.

The last line is essential. An open TBW value does not become a rating because an arithmetic requirement was calculated. An unlisted controller does not become “fixed BOM” because the buyer received three matching samples. The proposal records unknowns so they can be closed before approval or explicitly accepted as out of scope.

Record 3: sample identity and chain of custody

Before destructive or long-duration testing, each sample receives an identity record. A useful record includes photographs of both sides, label revision, serial or trace code, reported capacity, firmware, interface identity and the host or adapter used to read it.

For SD media, CID and CSD can help distinguish and investigate samples, but host-visible identity is not a complete view of raw NAND or controller internals. For SSDs, model, serial, firmware, namespace/capacity and relevant health fields should be captured before and after testing. The Linux MMC framework and NVMe specifications document interface-level observation and test mechanisms [10][11].

The custody record also states who supplied the samples and when. This prevents a later report from being attached to an unidentified replacement or to a device reformatted after failure.

Record 4: test plan and observation boundary

A test name is not yet a method. “Capacity test,” “speed test” and “power-cycle test” become reviewable only when inputs and outcomes are defined.

F3 can write and verify data across available flash addresses and is useful for false-capacity and aliasing checks [6]. It cannot expose raw NAND error margin or hidden remapping. fio can define transfer size, mix, queue depth, duration, verification and latency percentiles [7]. A one-minute fresh-drive result still does not represent sustained overwrite after cache exhaustion.

The plan must state these observation limits. A host-visible pass means the defined host-visible checks passed. It does not mean that every internal block is physically defect-free or that all future lots will behave identically.

Record 5: raw evidence plus a readable summary

The summary should never replace the raw evidence. A practical package keeps:

• the exact test configuration or job file;
• tool name, version and command line;
• machine, operating system, driver, adapter and power settings;
• start/end time, duration, ambient and device temperatures;
• complete stdout, logs, error counters and checksum manifests;
• plots derived from preserved data, with axis, unit and sampling interval;
• sample identity mapped to each file;
• a signed or versioned decision summary.

A chart without raw points is hard to audit. A screenshot without a command line is hard to reproduce. A result without a sample identity is hard to connect to production. The evidence pack keeps all three relationships intact.

Record 6: acceptance limits and exception disposition

Pass criteria are written before the final result is reviewed. Typical criteria can include minimum sustained throughput, maximum permitted p99 latency, zero end-to-end checksum mismatches, a required number of successful boot cycles or a list of prohibited recovery states after power loss.

Not every result is simply pass or fail. A professional disposition can be:

An exception list records the evidence, consequence, owner and closure action. It prevents a waived issue from disappearing between sample approval and purchase order.

Sample size: report what zero failures can and cannot support

Suppose five devices each complete 200 controlled interruptions, producing 1,000 interruption events with no prohibited recovery outcome. The rule-of-three approximation gives an upper 95% event-probability bound near 3/1,000 = 0.3% under independent, representative Bernoulli trials. NIST documents exact binomial limits for small or zero event counts [8].

That calculation is not a field-failure-rate claim. Cycles on one fixture can be correlated; five devices may come from one lot; the interruption timing may cover only defined phases; field temperature, power ramps and filesystem states may differ. The correct statement is narrower: zero prohibited outcomes were observed in 1,000 defined events on five identified samples under the recorded method.

The evidence pack preserves both the count and those boundaries. It does not turn a small test into an unsupported reliability percentage.

Record 7: the approval boundary

The approval page states exactly what was accepted:

• configuration identifier and revision;
• sample identifiers covered by the decision;
• host and workload boundaries;
• ratings and measured criteria that passed;
• accepted exceptions or restrictions;
• fields that must remain fixed;
• allowed substitutions, if any;
• events that require notification, review or requalification;
• approver, date and linked evidence versions.

This page is the reference for a repeat order. “Same capacity and speed” is not enough when a controller, NAND, firmware or package change could alter compatibility, sustained performance, thermal behavior, power recovery or endurance.

Record 8: incoming-lot comparison and change control

Incoming inspection compares the shipment with the purchase and approval baseline [4]. The plan may check quantity, packaging, labeling, date/trace codes, reported identity, firmware, capacity and a risk-based sample of functional or full-address tests.

The comparison is not automatically 100% testing. Sample size and method depend on lot size, defect consequence, prior evidence and buyer agreement. A sampled pass supports the stated acceptance plan; it does not prove every unit is defect-free.

Change control then defines the response to a new firmware, controller/NAND scope, PCB/package revision, manufacturing process or end-of-life notice. A label-only change may need document review. A controller or NAND change may require broader workload, power, thermal and compatibility qualification. The effect determines the work, not the supplier's adjective for the change.

Record 9: field return and RMA continuity

When a field problem occurs, the original evidence pack becomes the investigation baseline [5]. The RMA record adds symptom, timestamps, host, workload, power history, environment, device identity, logs and reproduction attempts. It preserves user-data recovery needs before destructive analysis.

The conclusion distinguishes observed fact, confirmed cause, contributing factor and untested hypothesis. If the returned identity differs from the approved baseline, that difference is itself an investigation result. If it matches, the retained qualification logs help determine what field condition was not represented.

What Kalstor commits to at the evidence level

Kalstor's useful commitment is procedural and specific:

1. record the application information supplied by the buyer;
2. identify the proposed configuration and its open fields;
3. state which tests and documents are included for the project;
4. connect summaries to identified samples and retained evidence where agreed;
5. define the approval and repeat-order boundary in writing;
6. confirm current MOQ, price, lead time and quote validity at RFQ/order stage;
7. avoid implying inventory, fixed components, ratings or certificates that are not confirmed for the quoted product.

Evidence availability varies by configuration and may require NDA, buyer-host access, paid testing or source-partner participation. The website describes the workflow; the quotation and approval record define the deliverable project.

Buyer checklist before requesting a sample

Provide the following to make the first proposal technically useful:

• product type, interface/package and target capacity;
• host model, controller, OS/firmware and connector information;
• measured average/peak writes, read/write pattern and duty cycle;
• service years, retention window and acceptable performance limits;
• operating/storage temperature and credible power events;
• required fixed-BOM, firmware, label, preload and packaging fields;
• target market, compliance documents, sample quantity and forecast;
• target date and which evidence must be reviewed before volume approval.

The objective is not more paperwork. It is to make each technical and commercial claim traceable to a source, method and configuration. That is how a buyer can compare candidates, approve a sample without overreading it, and know what a repeat order is expected to match.