# Linked runtime content fingerprint

> Embedding hosts can read one VM-owned receipt that identifies the Harn runtime content linked into their executable:

Website: https://harnlang.com/runtime-content-fingerprint.html

This page documents Harn, which is pre-1.0. Language, standard library, and CLI APIs may change. If the intended version is unclear, clarify before using this page.

---

Embedding hosts can read one VM-owned receipt that identifies the Harn runtime
content linked into their executable:

```rust
let fingerprint = harn_vm::runtime_content_fingerprint();
println!("{}", fingerprint.content_sha256);
```

The function returns `&'static RuntimeContentFingerprint` with these fields:

| Field | Meaning |
| --- | --- |
| `schema` | Receipt schema, currently `harn.runtime_content_fingerprint.v1` |
| `content_sha256` | Composite identity of the linked runtime content |
| `harn_version` | Version of the linked `harn-vm` crate |
| `embedded_stdlib_sha256` | Stable digest over every embedded module name and source byte |
| `compatibility.codegen_fingerprint` | Build-time digest of compiler and code-generation inputs |
| `compatibility.bytecode_schema_version` | Bytecode cache format identity |
| `compatibility.linked_program_schema_version` | Linked-program envelope identity |
| `compatibility.linker_algorithm_version` | Linker behavior identity |
| `compatibility.build_features` | Closed boolean record of every Cargo feature compiled into `harn-vm` |
| `source_revision` | Full source object ID when measured, otherwise `null` |

`content_sha256` includes `harn_version`, `embedded_stdlib_sha256`, and every
compatibility field. It excludes the receipt schema, its own digest, and
`source_revision`. A build stamp alone therefore cannot claim different linked
content. The optional revision remains useful provenance, but consumers must
keep `null` distinct from an observed revision.

The embedded standard-library digest has one owner. Bytecode cache invalidation
and this public receipt consume the same VM function, so they cannot drift into
parallel definitions.

The build-feature record distinguishes the distributed full runtime from lean
`default-features = false` embeddings and from optional instrumentation builds.
An owning test compares the record with every feature declared in
`crates/harn-vm/Cargo.toml`, so adding a feature without extending the typed
receipt fails closed.

`harn version --json` projects this receipt at
`data.runtime_content_fingerprint`. Embedding hosts should project the typed VM
value through their existing version or diagnostic surface instead of hashing
files or reconstructing compatibility fields themselves.

---

## Read next

- [Embedding Harn in Rust](https://harnlang.com/embedding-rust.md)
- [Portable kernel contract](https://harnlang.com/portable-kernel-reference.md)