# Library

`npm install epcis.dev` and import. The barrel exports are the exact
functions the CLI verbs run — one engine, no second SDK, so anything you
verify at the command line holds in your process, byte for byte.
Everything runs in-process: no network, no account, no service.

## The barrel

| export | what it is |
|---|---|
| `translate` | EPCIS 1.1/1.2/2.0 XML → 2.0 JSON-LD with a per-job round-trip fidelity report |
| `TranslationError` | the typed translation failure |
| `validateEpcis` | verdict against the pinned official GS1 EPCIS 2.0.1 JSON schema |
| `getEpcisValidator` | the compiled document/event validator |
| `getQueryValidator` | the compiled query-schema validator |
| `eventHash` | the CBV 2.0 §8.9 standardized event hash (OpenEPCIS-vector compatible) |
| `canonicalJson` | the §8.9 canonicalization step, exposed |
| `preHashString` | the §8.9 pre-hash string, exposed |
| `project` | `project(event)` — the conformant EPCIS 2.0 projection; always validates against the pinned schema |
| `PINS` | sha256 pins of the vendored official GS1 artifacts |
| `getPin` | one pin by artifact name |
| `ARTEFACT_NAMES` | the pinned artifact names |
| `gateway` | the worker gateway (capture/query/translate/MCP doors) — mount or drive in-process |
| `ALL_CHECKS` | the advisory 18-check conformance suite |
| `runSuite` | run the advisory suite against a target |
| `buildEvidenceBundle` | the evidence bundle of a run (hash tree over full transcripts) |
| `rejudgeEvidenceBundle` | offline replay of a recorded bundle |
| `verifyEvidenceBundle` | offline hash-tree verification of a bundle |
| `createReferenceTarget` | the built-in hermetic reference implementation |
| `REFERENCE_TARGET_DESCRIPTOR` | the reference target's descriptor |

Shapes worth knowing before you code:

- `validateEpcis(doc)` returns `{ valid, errors }` — the schema
  provenance (`artefact`, `version`, `sha256`) is available from `PINS`;
  the CLI's `validate --json` assembles both for you.
- `eventHash`, `preHashString` and `canonicalJson` are **async** — they
  return promises; `await` them.
- The tarball ships its fixtures: `node_modules/epcis.dev/golden-corpus/`
  is importable test data for your own suite, and
  `node_modules/epcis.dev/AGENTS.md` is the operating manual, greppable
  where you already are.

## Proof — five lines, run

Executed against the published `epcis.dev@0.1.0`, with a fixture from the
tarball:

```js
// check.mjs
import { validateEpcis, eventHash } from "epcis.dev";
import { readFileSync } from "node:fs";

const doc = JSON.parse(readFileSync(process.argv[2], "utf8"));
console.log(validateEpcis(doc));
console.log(await eventHash(doc.epcisBody.eventList[0]));
```

```
$ node check.mjs \
    node_modules/epcis.dev/golden-corpus/valid-standard/object-event-shipping.json
{ valid: true, errors: [] }
ni:///sha-256;e5624abcce4b2fc226743e8891f69c12a07ad508953749d9b9ede6771424f91e?ver=CBV2.0
$ echo $?
0
```

The same fixture POSTed to the hosted doors returns the same verdict and
the same `ni` URI — see [Validate & hash](/docs/reference/validate-hash/).
One engine, every face.

---

**Proof, not adjectives.** This build could not verify the gateway's test suite green, so no sentence on this page claims a passing run — the last verified run is recorded in the repository's own CI, not here. Live on this origin, no key: POST /translate, /validate, /hash. No conformance attestation has ever been issued. The dated ledger is /what-ships-today/.