Technical specification

The system describes a persistent identity and interaction layer for an artwork, a historical interpretation or another creative subject. The current references deliberately differ: Trevor Jones's work has a living artist who can author its character; Mary Somerville and Patrick Geddes require source-grounded, visibly interpretive historical treatment. They share infrastructure, not a generic personality.

1. Discover the identity. Start from a direct manifest, a configured artwork NFT, a prototype catalogue entry or an ERC-8004 registration advertising a LivingArt service.
2. Verify authority and integrity. Check creator and owner bindings, lifecycle state, declared hashes and versioned resources. A failure is shown as unverified rather than silently ignored.
3. Resolve permitted replicas. Retrieve canon, sources, inventory, interaction and replication documents in declared order. Content-addressed fallbacks must reproduce the same bytes.
4. Plan against the installation. Compare required text, vision, speech, transcription, camera and image capabilities with what is actually available on the device or hosted service.
5. Choose a disclosed route. Offer canonical hosted, compatible offline, personal-provider or presentation-only operation as ready, requiring setup, unverified or blocked.
6. Run the interaction contract. Preserve source citations, epistemic state, privacy scope and generated-media disclosures. Camera, image and speech actions complete in an explicit order around model inference.

• Creator authority governs recognised identity, approved character material, source policy and canonical presentation.
• Owner authority governs the current operational manifest, hosting and service choice within the published identity boundaries.
• An operator runs a website or installation under that operational authority.
• A visitor receives an ephemeral session and no authority over identity, memory, funds or wallet assets.
• An independent implementer may use permitted public material without the token owner's permission, but must label the result as an independent interpretation and follow source rights.

Three client claims

A canonical client uses the advertised canonical service. A compatible independent client may replace models or retrieval while preserving evidence, rights and disclosure rules. A presentation-only client may show declared media but must not imply that live conversation is present.

The tested Ethereum profile uses ERC-721 as the ownership and identity anchor and ERC-6551 as the identity's account. Creator and owner pointers bind versioned offchain documents by URI and hash. Large evidence corpora, private conversation, raw camera frames and model execution stay offchain.

The ERC-6551 account does not turn unsolicited wallet deposits into canon: presentation uses a curated inventory and unknown assets remain quarantined. A separate, policy-bounded conversation fund is implemented in contract code but not deployed for Mary. Live ERC-8004 registration and x402 payment are planned integrations, not completed capabilities.

The implementation also has a reviewed knowledge structure for entities, assertions and events. Promoting it into the public protocol set, with portable conformance fixtures, remains in progress.

Source records distinguish discovery, retrieval, indexing, paraphrase, quotation, generation and permanent storage. A retrievable item is not automatically evidence, training data or content that may be copied to IPFS or Arweave. Private dialogue, personal memory and raw camera material remain offchain by default.

Mary's reviewed release currently has a Filebase IPFS copy, an independently served HTTPS fallback and deterministic local CAR repair files. A production release still requires the planned second independent IPFS pin and verified archival repair route.

• The contracts and creator controller need independent security review before valuable mainnet use.
• The resolver works in the reference application, but a public deployment needs a reviewed public-only catalogue and a restricted remote-fetch policy. Unpublished prototype material must not be exposed.
• ERC-8004 registration, x402 payment and a live conversation fund have not been deployed for the Mary reference.
• Independent resolver test vectors, invalid fixtures and a second implementation are needed before interoperability can be claimed.
• Model qualification reports need broader historical, character, false-premise, vision and generated-media evaluation.
• Windows reference-image fidelity, peak resource use, interruption behaviour and unattended exhibition soak testing still need quantitative results.
• Trevor and Patrick are not yet content-addressed onchain reference identities.