Qué recibe un comprador OEM de Kalstor: el paquete de evidencia flash

Un comprador OEM no necesita otra promesa de que una tarjeta o SSD es “estable”. Necesita un registro que responda seis preguntas: qué aplicación se describió, qué configuración se propuso, qué muestras físicas se probaron, cómo se probaron, qué pasó o quedó abierto y qué debe coincidir en un pedido repetido.

Ese registro es el paquete de evidencia en un proyecto Kalstor. No es un certificado universal ni es idéntico para microSD, SSD, módulos USB, eMMC o UFS. Es un conjunto controlado de registros cuyo alcance se acuerda antes del volumen [1][2]. La producción y sus pruebas corresponden al socio de origen aplicable; Kalstor conecta requisitos, configuración, evidencia revisable y control comercial sin presentar capacidades no demostradas como hechos.

Es un registro de decisión, no una carpeta de marketing

Una carpeta llena de datasheets puede dejar sin respuesta la pregunta principal: ¿la muestra aprobada y el producto pedido tienen la misma configuración relevante? Un paquete útil sigue esta cadena:

requisito de aplicación
-> configuración propuesta
-> muestras identificadas
-> prueba controlada y resultado bruto
-> revisión de excepciones
-> límite de aprobación
-> comparación del lote
-> cambio o RMA

Una ficha describe un rango nominal, pero no prueba el host del comprador. Un benchmark mide una muestra, pero no demuestra qué se enviará después si la configuración no está identificada. Un certificado respalda un sistema de calidad o materiales, pero no sustituye resistencia, compatibilidad o integridad a nivel de producto.

Kalstor separa cuatro clases:

Registro 1: resumen de aplicación

El paquete comienza con datos del comprador, no con una etiqueta de memoria. Como mínimo registra:

Los campos vacíos permanecen visibles. Si el cliente indica “cámara 4K, 256GB” sin bitrate, flujos, duty cycle o temperatura, Kalstor identifica lo que falta, pero no inventa retención ni resistencia.

Ejemplo numérico

Un grabador con cuatro flujos y 32 Mbit/s agregados produce:

Escritura diaria = 32 Mbit/s × 10,8 = 345,6GB/día
Escritura anual = 345,6 × 365 ÷ 1.000 = 126,1TB/año
Escritura en cinco años = 630,7TB
Equivalentes diarios sobre 256GB = 345,6 ÷ 256 = 1,35

No es un rating de una tarjeta Kalstor. Define la carga que la propuesta debe atender. El grabador también puede requerir ventana de retención, margen de pico, vueltas completas y cortes controlados. La resolución no proporciona esos valores.

Registro 2: hoja de configuración propuesta

Según producto y divulgación, puede incluir:

• parte comercial Kalstor y revisión documental;
• formato, interfaz, capacidad y dimensiones;
• modelo reportado, CID/CSD, firmware o identidad NVMe/SATA;
• alcance de controlador y NAND cuando esté disponible y acordado;
• velocidad, resistencia y temperatura ligadas al documento fuente;
• etiqueta, empaque, precarga o aprovisionamiento;
• cantidad de muestras, vigencia, plazo y MOQ;
• campos fijos, equivalencias permitidas y puntos pendientes.

La última línea evita falsas conclusiones. Un TBW abierto no se convierte en rating porque exista un cálculo. Un controlador no listado no queda fijo porque tres muestras coincidan. Los desconocidos se cierran antes de aprobación o se aceptan expresamente fuera de alcance.

Registro 3: identidad y custodia de muestras

Antes de pruebas destructivas o largas se documenta cada muestra: fotos de ambas caras, revisión de etiqueta, serial o trazabilidad, capacidad, firmware, identidad y host o adaptador.

En SD, CID y CSD ayudan a distinguir muestras, pero no exponen toda la NAND ni el controlador. En SSD conviene capturar modelo, serial, firmware, capacidad y salud antes y después. El framework MMC de Linux y la especificación NVMe describen mecanismos de interfaz [10][11].

También se registra quién suministró la muestra y cuándo. Así un informe no termina asociado a un sustituto o a una unidad reformateada después de fallar.

Registro 4: plan y límite de observación

“Prueba de capacidad”, “prueba de velocidad” y “ciclo de energía” solo son revisables si se definen entradas y salidas.

F3 escribe y verifica direcciones disponibles y ayuda a detectar capacidad falsa o aliasing [6]; no ve margen ECC bruto ni remapeo oculto. fio define tamaños, mezcla, cola, duración, verificación y percentiles [7]; un minuto con unidad nueva no representa sobrescritura sostenida tras agotar caché.

Un Pass visible al host significa que pasaron los controles visibles definidos. No demuestra que cada bloque físico sea perfecto ni que todo lote futuro sea idéntico.

Registro 5: evidencia bruta y resumen legible

El resumen no reemplaza la evidencia. Un paquete práctico conserva:

• configuración exacta o job file;
• herramienta, versión y comando;
• máquina, sistema, driver, adaptador y energía;
• hora, duración y temperaturas;
• salida completa, logs, contadores y manifiestos;
• gráficas con datos, ejes, unidades e intervalo;
• identidad vinculada a cada archivo;
• resumen firmado o versionado.

Una gráfica sin puntos es difícil de auditar. Una captura sin comando no se reproduce. Un resultado sin identidad no se conecta con producción.

Registro 6: límites y disposición de excepciones

La aceptación se escribe antes de revisar el resultado final. Puede incluir rendimiento sostenido mínimo, p99 máximo, cero mismatch extremo a extremo, ciclos de arranque o estados prohibidos tras corte.

La lista de excepciones conserva evidencia, consecuencia, responsable y cierre. Una dispensa no desaparece entre muestra y orden.

Tamaño de muestra: qué significa cero fallas

Si cinco dispositivos completan 200 cortes cada uno, hay 1.000 eventos sin resultado prohibido. La regla de tres aproxima el límite superior del 95% a 3/1.000 = 0,3% bajo ensayos Bernoulli independientes y representativos. NIST documenta límites binomiales exactos para conteos pequeños o cero [8].

No es una tasa de campo. Los ciclos de un fixture pueden estar correlacionados, cinco dispositivos pueden ser de un lote y las fases probadas pueden no representar temperatura, rampa eléctrica o filesystem de campo. La frase correcta es más estrecha: se observaron cero resultados prohibidos en 1.000 eventos definidos sobre cinco muestras identificadas bajo el método registrado.

Registro 7: límite de aprobación

La página de aprobación declara:

• identificador y revisión de configuración;
• muestras cubiertas;
• límites de host y carga;
• ratings y criterios medidos que pasaron;
• excepciones o restricciones;
• campos que deben permanecer fijos;
• sustituciones permitidas;
• eventos que requieren aviso o recalificación;
• aprobador, fecha y versiones de evidencia.

Es la referencia del pedido repetido. “Misma capacidad y velocidad” no basta si un cambio de controlador, NAND, firmware o paquete altera compatibilidad, sostenido, térmica, energía o resistencia.

Registro 8: lote entrante y cambios

La inspección compara envío, compra y línea base [4]. Puede revisar cantidad, empaque, etiqueta, códigos, identidad, firmware, capacidad y una muestra funcional o de dirección completa basada en riesgo.

No implica automáticamente prueba al 100%. Tamaño y método dependen de lote, consecuencia, evidencia previa y acuerdo. El muestreo respalda el plan declarado; no demuestra que toda unidad esté libre de defecto.

El control de cambios define respuesta a firmware, controlador/NAND, PCB/paquete, proceso o EOL. Una etiqueta puede requerir revisión documental. Un cambio de controlador o NAND puede exigir calificación más amplia. Manda el efecto, no el adjetivo del proveedor.

Registro 9: continuidad en RMA

Ante una falla, el paquete original es la línea base [5]. El RMA añade síntoma, tiempo, host, carga, energía, ambiente, identidad, logs y reproducción. Protege la recuperación de datos antes del análisis destructivo.

La conclusión distingue hecho observado, causa confirmada, factor contribuyente e hipótesis. Si la identidad devuelta difiere de la aprobada, esa diferencia ya es un resultado. Si coincide, los logs ayudan a identificar qué condición no se representó.

Compromiso de Kalstor a nivel de evidencia

Kalstor se compromete de forma concreta a:

1. registrar la información de aplicación entregada;
2. identificar configuración propuesta y campos abiertos;
3. declarar pruebas y documentos incluidos;
4. conectar resúmenes con muestras y evidencia cuando se acuerde;
5. definir por escrito aprobación y repetición;
6. confirmar MOQ, precio, plazo y vigencia en RFQ/orden;
7. no insinuar inventario, componentes fijos, ratings o certificados sin confirmar para el producto cotizado.

La disponibilidad varía y puede requerir NDA, acceso al host, prueba pagada o participación del socio. El sitio describe el proceso; cotización y aprobación definen el proyecto entregable.

Lista del comprador antes de solicitar muestra

Entregue:

• producto, interfaz/paquete y capacidad;
• host, controlador, sistema/firmware y conector;
• escrituras medias/pico, patrón y duty cycle medidos;
• años, retención y límites aceptables;
• temperatura y eventos eléctricos creíbles;
• campos fijos de BOM, firmware, etiqueta, precarga y empaque;
• mercado, documentos, muestras y previsión;
• fecha y evidencia requerida antes de volumen.

El objetivo no es producir más papel. Es hacer cada afirmación técnica y comercial trazable a fuente, método y configuración. Así se comparan candidatos, se aprueba una muestra sin exagerarla y se sabe qué debe coincidir en la repetición.