vortx-ai/emem/emem-device-traces

emem-device-traces

Network use. The calls in this skill send JSON to https://emem.dev and receive JSON from it. https://emem.dev is the service that the MCP server of the plugin connects to. An answer is saved as a JSON file only so that jq can print a summary of it or build the next body. Nothing received is run. A trace is data: a JSON list of event counts and hashes, not a program.

A device can sign more than a reading. It can also sign a trace of what its operating system did while it made the reading. The trace records scheduler, memory, storage and network activity in fixed windows. Each segment links to the one before it, and the trace binds the outputs that the device emitted. emem stores these records as emem.os_trace.v1 and names them emem:trace:<cid>.

What ships and what does not

The verifier side is live. The platform registry lists hardware roots of trust (TPM, DICE, TDX, SEV-SNP, Secure Enclave, Android StrongBox and others) as candidates with provisional anchors. They admit no device yet.

emem has one enrolled device: the operator's own software-only Linux host. Do not tell a user that their robot can enrol with hardware attestation. That path ends in a rejection today.

Step 1: list the enrolled devices

curl -sf https://emem.dev/v1/devices

Read count. For each entry of devices[], read device_key, platform_id, profile_id, assurance, endorsed_by and traces.

On 7 November 2026 this returned count: 1. The device has platform generic.linux-host, profile host.counters.v1, assurance operator_endorsed by operator.vortx.v1, and one trace.

Step 2: resolve a trace token

Send this body to POST https://emem.dev/v1/trace_resolve:

{"token": "emem:trace:mxyer5c2oxn4ud3xqbtnaxcxhdv4kkxiu67q32inbwxgpa7r3s6a"}

Save the answer as trace.json. Then print a summary:

jq -c '{resolved, profile: .trace.device.substrate_profile, outputs: .trace.outputs}' trace.json
jq -c '.trace.segments[] | {seq, layer, encoding, event_count}' trace.json

On 7 November 2026 the token resolved to profile host.counters.v1 with outputs: [] and four linux.ftrace.v1 segments:

The answer also has trace_cid, prev_trace_cid and a reverify string that names the call for step 3.

Step 3: re-verify the trace

Send the record back with its profile. jq builds the body from the saved answer:

jq -c '{trace: .trace, profile: .trace.device.substrate_profile}' trace.json > verify_req.json

The body has this shape, with the whole record from trace.json as trace:

{"trace": {"schema": "emem.os_trace.v1"}, "profile": "host.counters.v1"}

Send verify_req.json as the body of POST https://emem.dev/v1/trace_verify. Save the answer as verdict.json. Then print the result:

jq '{verdict, coverage: .report.coverage, reasons: .report.reasons}' verdict.json

On 7 November 2026 this returned verdict: "admit", all four required layers in coverage.present, and no reasons.

Over MCP, call emem_trace_verify with the same object as its arguments. The plugin's MCP server does not list this tool, but tools/call runs it by name. emem_tools returns its schema. No MCP tool lists devices or resolves a trace token, so use REST for steps 1 and 2.

To see a failure, change one count before you send the record:

jq -c '{trace: (.trace | .segments[2].event_count += 1), profile: .trace.device.substrate_profile}' trace.json > bad_req.json

Send bad_req.json as the body of POST https://emem.dev/v1/trace_verify. Read verdict and report.reasons in the answer.

On 7 November 2026 this returned verdict: "reject" with {"code":"chain_broken","seq":3}. Each segment commits to the digest of the segment before it. An edit to segment 2 changes its digest, so the link in segment 3 breaks.

trace_verify is stateless. It checks these items:

• the schema and the profile
• the segment order and the digest chain
• clocks that increase inside the capture window
• the required layers, and duplicate digests
• the Merkle trace_root over the segment digests
• that the trace binds each output inside the window
• the Ed25519 signature of the device key (strict)

The report names each failed check, for example chain_broken, missing_layer, output_unbound or signature_invalid.

What a verdict proves, and what it does not

Enrolment evidence (emem.platform_attestation.v0) is one endorser signature, checked against a registered anchor. emem does not yet parse certificate chains, TPM quotes, measurement matches or fresh nonces. POST /v1/enroll_verify checks a piece of evidence and does not store it. It returns HTTP 200 for any JSON body.

For example, send this body to POST https://emem.dev/v1/enroll_verify:

{"platform": "nvidia.jetson-orin", "attestation": {"schema": "emem.platform_attestation.v0"}}

On 7 November 2026 this returned verdict: "reject" with the error `missing field eat_profile `.

Step 4: read the registries

curl -sf https://emem.dev/v1/device_platforms
curl -sf https://emem.dev/v1/trace_encodings

In the platform registry, read manifest_cid. For each entry of registry.platforms[], read id, status, root_of_trust, and the id and provisional of each entry of trust_anchors[]. In the encoding registry, read manifest_cid and the id of each entry of registry.encodings[].

On 7 November 2026 the platform registry had 17 platforms, all with status candidate. The only anchor that was not provisional was operator.vortx.v1 on generic.linux-host (software_only). Its manifest_cid was gi6lw3ekbpd7soeperslxjgeljl6c3h7q6ngdcykfp2yucpcbsya.

The encoding registry had 8 encodings: linux.ftrace.v1, linux.ebpf.raw, linux.hwmon.v1, zephyr.ctf.v1, ros2.bag.v2, android.perfetto.v1, nvidia.nsys.v1 and apple.os_signpost.v1. Its manifest_cid was fmyxah55fjr2vfzmktjdghutg37g2qdt2zmu7ub2dtgtpn64otga.

Each registry is content-addressed. When you say what the registry admitted on a date, cite the manifest_cid of that date.

Related

For the design and the roadmap, see docs/robots.md in the emem repository. For a fact that a device made, verify its receipt with `emem-verify-receipt`, as for any other fact.