Live

ATE / ATP Results

RTMify Live can ingest per-unit as-built evidence from automated test equipment and acceptance test procedures through the same JSON test-results API used for generic execution evidence. This is the clamp-the-board-into-the-rig path: one physical unit, one serial number, one executed station run or ATP packet, and one set of pass/fail plus measured output. If your station software or ATP workflow can emit JSON, Live can store that execution, tie it to the unit serial number, scope it to a product, and roll the linked test results back into requirement verification.

What Live actually supports today

Live does not have a separate native ATE or ATP file format. The supported path is the existing POST /api/v1/test-results contract or an equivalent JSON file dropped into the inbox. In practice, that means you export or transform station output into RTMify’s execution schema, preserving the per-unit serial number and station-run identity.

When to use this path

ATE station output

Use this path when a physical unit is clamped into a fixture or rig and the station already knows the serial number, product identifier, pass/fail result, and underlying test step IDs.

ATP execution records

Use it when an executed acceptance test procedure produces structured per-unit results and you want those results tied back to the existing Test and Requirement graph instead of left in an external worksheet or PDF packet.

Two ingestion paths

HTTP POST

Best for station controllers, ATP runners, or post-processing scripts running on the same machine as Live.

POST http://127.0.0.1:8000/api/v1/test-results

File-drop inbox

Best when the station can write files but should not call the API directly. Live polls the inbox and ingests the same JSON shape automatically.

~/.rtmify/inbox/

How ATE / ATP concepts map to the JSON schema

ATE / ATP concept RTMify field Notes
One station run on one individual unit, or one executed ATP packet for that unit execution_id Must be unique per execution for idempotent replacement.
Execution timestamp executed_at ISO-8601 timestamp.
Unit or board serial number serial_number Enables unit history queries.
Known product build or assembly identifier full_product_identifier Creates product-scoped history when the Product exists in Live.
Station or runner metadata executor Opaque JSON object. Use it for station name, software version, fixture ID, operator, or line metadata.
Source system label source Opaque JSON object. Use it for ATE/ATP provenance such as MES, factory cell, or acceptance-run context.
One measured or asserted test step test_cases[] Each test step maps to one existing Test node through test_case_ref.
Station step / ATP case identifier test_cases[].test_case_ref Must point at an existing Test ID if you want resolved traceability.
Pass/fail outcome test_cases[].status Allowed values are passed, failed, blocked, skipped, error.
Numerics or measured values test_cases[].measurements Structured array; preserved on the TestResult node.
Logs, attachments, screenshots test_cases[].attachments Structured array; preserved on the TestResult node.

Example per-unit as-built payload

This is the same schema documented on the generic Test Results page, but populated the way an ATE or ATP workflow would normally think about one specific tested unit.

{
  "execution_id": "ate-asm1000-revc-unit042-2026-03-18T14:03:11Z",
  "executed_at": "2026-03-18T14:03:11Z",
  "serial_number": "UNIT-042",
  "full_product_identifier": "ASM-1000-REV-C",
  "executor": {
    "station": "ATE-03",
    "fixture": "FCT-1000-REV-C",
    "software_version": "2.7.4"
  },
  "source": {
    "system": "production-ate",
    "procedure_id": "ATP-001",
    "procedure_revision": "C"
  },
  "test_cases": [
    {
      "result_id": "ate-042-power-on",
      "test_case_ref": "T-ATP-001",
      "status": "passed",
      "duration_ms": 820,
      "measurements": [{ "name": "supply_current_ma", "value": 118.2 }],
      "attachments": [{ "kind": "log", "path": "logs/unit-042.txt" }]
    },
    {
      "result_id": "ate-042-radio-selftest",
      "test_case_ref": "T-ATP-002",
      "status": "passed"
    }
  ]
}

What happens on ingestion

  1. Validates the JSON payload structure.
  2. Creates or updates a TestExecution node and one TestResult node per test case.
  3. Stores serial_number, executor, source, measurements, and attachments as evidence properties.
  4. If full_product_identifier resolves, creates a FOR_PRODUCT edge from the execution to the Product.
  5. Creates HAS_RESULT and EXECUTION_OF edges tying those results back to existing Test nodes.
  6. On the next workbook sync, updates the requirement-level verification rollups that depend on those tests.

As-built evidence is product-aware, not manufacturing-history-complete

Live can store serial-bearing as-built execution evidence and tie it back to a Product, but it is not yet a full manufacturing execution system or complete production history record. The current graph models per-unit test execution evidence, not lot genealogy, rework routing, or formal device history packet control.

Queries that matter for production test

"Show unit history for serial UNIT-042."
"List serial-bearing executions for ASM-1000-REV-C."
"Show the stored execution ate-asm1000-revc-unit042-2026-03-18T14:03:11Z."
"Show latest verification status for REQ-047 after ATP execution."
"List dangling test results that did not resolve to a known Test node."
"Show every serial number verified against the product ATP tests."
  • get_execution returns the stored execution envelope, including serial number, executor/source metadata, measurements, and attachments.
  • get_unit_history gives serial-number history for one unit.
  • get_product_serials gives serial-bearing executions scoped to a Product.
  • get_verification_status shows how those ingested results affect requirement rollups.

Cross-check with the generic test-results contract

This page is an as-built production-test framing of the same ingestion contract documented in Test Results API. Use that page for the canonical field-by-field contract and bearer-token details. Use this page when you need to explain to operators, QA, or manufacturing how per-unit ATE and ATP evidence lands in the Live graph.