vortx-ai/emem/emem-research-grade-citation

emem-research-grade-citation

Network use. The commands in this skill send JSON to https://emem.dev and receive JSON from it. Where a step says so, they also receive an image or a raster file. https://emem.dev is the service that the MCP server of the plugin connects to. The commands do not execute what they download. This skill ships no scripts. The commands read no environment variable, key or credential. They read only local files that an earlier step saved from https://emem.dev.

A signed fact proves which responder served which bytes. It does not say which quantity those bytes estimate. A reviewer needs both: the token that pins the bytes, and a sentence that names the estimand. This skill writes that sentence from the fields that emem returns. It also says where those fields stop.

Step 1: read the fields of each fact

Call emem_recall with this body:

{"cell": "defi.zb493.zezo.zcb35", "bands": ["copdem30m.elevation_mean", "esa_worldcover.lc_2021"]}

Without MCP, send the same body to the REST endpoint, POST https://emem.dev/v1/recall. Save the answer as facts.json. Then print the facts and the spatial basis:

jq -c '.facts[] | {band, value, unit, observed_at, fn: .derivation.fn_key,
       args: .derivation.args, source: .sources[0].id, token: .memory_token}' facts.json
jq '.spatial_basis' facts.json

The elevation line for this Bengaluru cell on 7 November 2026:

{"band":"copdem30m.elevation_mean","value":918.637939453125,"unit":"m","observed_at":"2021-04-30T00:00:00Z",
 "fn":"copernicus_dem_30m_aws_pixel@1","args":[12.97679089393182,77.59005965949524,"reader=cog-pixel-floor@2"],
 "source":"https://copernicus-dem-30m.s3.amazonaws.com/Copernicus_DSM_COG_10_N12_00_E077_00_DEM/...DEM.tif",
 "token":"emem:fact:defi.zb493.zezo.zcb35:gzfrgbobepbuxzgizwp2a4if6nlsgporsezb7hfthgds6pfnapka"}

This value and token were the same on 28 September 2026. The DEM is a static layer, so the fact does not change. The WorldCover line gives the value 10 (lccs_class, observed 2022-10-28) from tile N12E075. Class 10 is "Tree cover" in the ESA WorldCover legend.

On 7 November 2026, spatial_basis gave a cell edge of 9.55 m (latitude) by 9.31 m (longitude) for this cell. It does not give a resolution for each band. Take the resolution from the source product.

Step 2: write the estimand for each band

No fact has an estimand or support field. Write one sentence for each band from the fields in step 1. An example:

Elevation is the Copernicus DEM GLO-30 value (observed 2021-04-30) of

the 30 m pixel that contains 12.97679 N, 77.59006 E, read with

cog-pixel-floor@2. It is a surface model (DSM), not bare earth.

Get these three items right in each sentence:

The band_metadata.pitfalls field of a fact often names a trap for the estimand. For copdem30m.elevation_mean on 7 November 2026, it said that GLO-30 is a surface model that includes building and canopy heights.

Step 3: read the unit and the valid range

GET https://emem.dev/v1/materializers lists the valid_range of each band with enforced_at_signing: true. The responder refuses to sign a value outside that range, so it never serves one. The list has pages (113 materialisers on 7 November 2026). The largest page is 100 entries. The responder clamps a larger page_size to 100 and does not give an error. Read both pages, then select the band. Send a GET to https://emem.dev/v1/materializers?page_size=100&page=1 and save the answer as mat1.json. Do the same with page=2 and save it as mat2.json. Then:

jq -c '.materializers[] | select(.band == "copdem30m.elevation_mean") | .valid_range' mat1.json mat2.json

On 7 November 2026 this printed {"enforced_at_signing":true,"max":9000.0,"min":-500.0,"unit":"m"}.

The band_metadata.value_range field in a recall is a different range. It describes the band and can disagree with the enforced range. On 7 November 2026 the WorldCover fact had the value 10 and a band_metadata.value_range of [0.0, 1.0]. The enforced range for esa_worldcover.lc_2021 was 0 to 100 (class). Cite the materialiser range: it is the range that the signature enforces.

Step 4: state the ULP window on derived values

You send a value that you computed over facts through POST /v1/derive (see `emem-sign-and-attest`). That call is a signed write. For a pure operation with a pinned code_cid, the responder computes the value again and compares it with your value.

The recomputation receipt always reports rule and the measured ulp_gap, on success and on failure. If your claim must be bit-identical, require ulp_gap: 0 and say so in the methods.

Step 5: explain why a number changed

Call emem_change_attribution with this body:

{"cell": "defi.zb493.zezo.zcb35"}

The plugin's MCP server does not list emem_change_attribution in its short tool list. The server runs it by name through tools/call. If your host calls only listed tools, or has no MCP, send the same body to the REST endpoint, POST https://emem.dev/v1/change_attribution. Save the answer as change.json. Then print a summary:

jq '{algorithm_key, split, n_env_evidence_bands, embedding: .observed.embedding.change,
     inputs: (.input_fact_cids | length), terms: (.terms | keys), ledger: .ledger_fact.token}' change.json

On 7 November 2026 this call returned change_attribution@1 with these values:

The call attributes change by evidence, not by size. Each term gives its evidence and its fact ids. No term gets a share of the delta, so do not report one. The attribution_note field says that the numeric split is roadmap work. The ledger is a fact with its own token (ledger_fact.token), so you can cite the evidence that you used. A second call with the same inputs gave the same token. The token resolves through POST /v1/memory_token/resolve to a fact with the band change_attribution.ledger.

Step 6: write the methods and data-availability text

A methods paragraph. Change it for each band:

Values were retrieved from the emem responder (https://emem.dev,

responder key 777er3yihgifqmv5hmc2wwmyszgddzderzhsx6rex4yoakwomvka)

on 2026-11-07. Each value is an Ed25519-signed fact identified by the

emem:fact: token listed in Table S1. The token resolves to the

byte-identical signed record, and its receipt verifies offline. [One

estimand sentence per band.]

The responder key is the responder.pubkey_b32 field of https://emem.dev/.well-known/emem.json. It had this value on 7 November 2026. Check it again on the day you write.

For data availability, list every token in a table such as Table S1. For a set of facts, you can also give one emem:bundle: token. Put the token of each fact next to it. A bundle names a set, but it does not pin its members. To fix the date of the record, pin a signed tree head and include the inclusion proofs (see `emem-transparency-log`).

Before you submit, do these checks:

1. Resolve every token and compare every number in the text with

`emem-verify-before-publish`.

1. Check each receipt with

`emem-verify-receipt`.

Reproduce a value without emem

sources[].id is the upstream file, and derivation.args holds the exact coordinates. Thus a reviewer can read the pixel again from the publisher with their own tools. A signature proves that emem served the value. It does not prove that the upstream product is accurate. Accuracy comes from the validation literature of the product. Cite that literature as usual.