How the Museum knows and cares for art

Status: working Museum data architecture and public education standard; not an adopted governance policy

A museum record begins with ordinary questions. What is the work? Who made it? Which object entered the collection? What happened before and after it arrived? What may the Museum do with it? What must survive for somebody to experience it in fifty years? Which image is the work, and which image merely documents it?

The Museum uses several complementary records. Each has a defined responsibility, and the same work or event may appear in more than one layer while retaining its own identity and purpose.

The explanation begins in ordinary language and then gives the machine-facing detail needed by artists, collectors, visitors, researchers, registrars, conservators, developers, data partners, and a future on-chain registry.

Eleven questions, eleven standards and vocabularies

One artwork through the architecture

Consider Casey Reas's CENTURY #31, accession number 6529NM.2026.001.01.

• Spectrum asks whether the Museum followed a controlled path from receipt to acquisition and accession, recorded title and rights, assigned a stable number, assessed condition, and accepted continuing obligations.
• CIDOC CRM can express creation, minting, transfer, title passage, custody receipt, accession, observation, and preservation as different events linked to the work, token, people, organizations, times, places, and sources.
• LIDO can deliver a public catalogue record with the title, creator, work type, materials and technique, events, repository, rights, credit line, and representations.
• PREMIS can distinguish the token metadata response, project script, dependency, rendering environment, still image, screenshot, manifest, and preservation package as different preservation Objects. It can record the validation, capture, rendering, migration, or recovery Events performed on them.
• PROV-O can state that a Museum screenshot was generated by a dated rendering activity using a particular generator response and environment, and was attributed to the Museum agent that performed the capture.
• Getty ULAN can identify Casey Reas independently of spelling or name form; AAT can control terms for work type, material, technique, and media.
• IIIF can present an approved still, video, or time-based documentation resource on a Canvas with rights and attribution, while identifying it as a representation rather than silently equating it with the live work.
• C2PA can retain or create a signed assertion about the history of a specific image or video file. Its signature does not prove that the file is the artwork, that the signer owns copyright, or that the token is authentic.
• BagIt can carry a dossier from one repository to another and verify that its listed files arrived unchanged.
• OCFL can retain version 1, version 2, and later migrations of that dossier without overwriting its history.
• CAIP-19 identifies the exact Ethereum ERC-721 asset as eip155:1/erc721:0xa7d8d9ef8d8ce8992df33d8b8cf4aebabd5bd270/100000031.

Together, the layers give the Museum a fuller record. They answer different questions: a checksum verifies particular bytes; a chain observation can show that an address held a token at a specified block; a catalogue record describes a work; none of those records preserves the software needed to run it.

The Museum's core entities

The Museum application profile keeps the following entities distinct even when a public page brings them together.

Distinctions the Museum keeps

The following separations are mandatory in Museum records:

1. The work, token, media, software, and documentation are related, but they are recorded as different things.
2. Receipt, wallet custody, legal title, acquisition, accession, cataloguing, technical verification, preservation, and display readiness are separate states, each supported by its own evidence.
3. A hash confirms that particular bytes match a declaration under a named algorithm. It does not establish authorship, artistic identity, completeness, legality, or significance.
4. A signature binds a signed statement to a signing key within a stated trust model. The statement itself still needs review.
5. An ontology gives the Museum shared concepts and relationships for describing events. Collection policy, legal rights, and event verification remain separate decisions.
6. A public page is the rights- and privacy-reviewed view of a record. Registrar and preservation records retain the supporting detail.
7. When the Museum does not know a fact, the record says so. It does not turn silence into a negative claim.

The Museum's application profile

The profile identifier is 6529NM_DATA_ARCHITECTURE_V1. Its machine-readable register is docs/data-architecture/profile.json. The register pins the authority, version or status, role, official source, and Museum implementation state for every layer. It is descriptive of this working standard and does not claim certification by any standards body.

Precedence

1. Evidence establishes whether a Museum assertion can be made.
2. Museum policy and a reviewed institutional act establish collection status.
3. The Museum record model preserves the assertion, evidence, authorship, review, version, and correction lineage.
4. Spectrum supplies the procedural control points.
5. CIDOC CRM supplies the cultural-heritage semantic integration model; PROV-O supplies general derivation and responsibility relations where that simpler vocabulary is useful.
6. PREMIS supplies preservation semantics; LIDO supplies the public exchange record; IIIF supplies presentation; Getty vocabularies supply controlled identifiers and terms.
7. C2PA, BagIt, OCFL, and CAIP-19 bind particular media assertions, transfer packages, storage versions, and chain assets.

When two standards overlap, the Museum does not force one to impersonate the other. The application profile states which layer owns the meaning and how a projection preserves it.

Implementation states

Every claimed implementation uses one of five states:

A later state never follows merely because a document says that it should. Validation evidence and the generated artifact must exist.

Current Casey Reas implementation

The first accession gives the Museum a substantial source record: seven exact chain identities; separate receipt, title, accession, custody, rights, condition, observation, and preservation assertions; public scholarship; and content-addressed evidence and release manifests. The complete assessment is in Casey Reas accession: implementation across the architecture.

At this release, CAIP-19-shaped asset identifiers are present for all seven objects, and Spectrum-derived accession controls are operational in the Museum workflow. The data can support substantial CIDOC CRM, LIDO, PREMIS, and PROV-O projections, but conformant exports have not yet been published. Getty authority reconciliation, IIIF manifests, C2PA manifests, RFC 8493 bags, and an OCFL repository remain unimplemented. The current public record identifies each as future work.

Education is part of stewardship

These pages are public because collection records should be useful beyond the registrar's office. Artists and collectors encounter the same questions the Museum does: what a work depends on, what a token identifies, what a file records, and what must be preserved for the work to remain intelligible.

The architecture makes those questions explicit and gives them durable, reviewable answers. It is part of the Museum's educational mission, and it remains open to correction through the reviewed repository that holds the collection record.

Stream and the later convergence phase

This profile stands on its own as the Museum's collections and preservation model. Once it is stable, the Museum will compare it with 6529Stream field by field, retain compatibility where the meanings match, and use explicit adapters where the formats differ. The comparison will be published with round-trip tests and pinned artifacts.

Source and revision discipline

Each standards page cites the responsible standards body rather than a vendor summary. Version claims were observed on 5 August 2026 and must be reviewed when an authority publishes a new stable release. Drafts are identified as drafts. Museum examples distinguish existing artifacts from planned implementations. Corrections are made through a reviewed commit and deterministic release manifest; they do not erase the prior publication.

Revision history

• 1.0.2 — 2026-08-16: replaced an internal publication instruction with a public statement of the capabilities that remain future work.
• 1.0.1 — 2026-08-15: copy-edited the public Research edition for direct museum language; no standard, implementation status, or interoperability claim changed.
• 1.0.0 — 2026-08-05: initial public Museum data architecture standard.