Solutions

Verifiable Digital Twins for Products and Documents

ObjectID provides two core solutions—Objects and Documents—to create tamper-evident, traceable digital twins anchored to a domain-linked digital identity. Each twin is associated with a URL, supports ownership transfer, and can be integrated into existing systems via APIs and standard identifiers (QR/NFC).

A twin is considered valid only when its Creator can cryptographically prove control of the Internet domain referenced by the twin’s URL (Domain Linked Verifiable Credential).


How validity verification works (Domain-Linked Identity)

ObjectID binds a Creator’s digital identity to a specific Internet domain (e.g., example.com). When an Object or Document is created, it includes a URL under that domain.

Verification checks typically include:

  1. Read the twin on-chain
    Retrieve the twin data (Object/Document) and its declared URL/domain, plus the Creator identity.

  2. Resolve the Creator identity
    Resolve the Creator’s DID (Decentralized Identifier) document and its keys.

  3. Verify the domain linkage
    Confirm that the domain hosts a Domain Linkage statement (e.g., under /.well-known/) that cryptographically links the domain to the Creator DID, and validate the signature chain.

  4. Match domain ↔ URL ↔ Creator
    The domain in the twin’s URL must match the domain that is linked to the Creator identity.

If these checks pass, the twin is valid. If they fail, the twin may still exist, but it is treated as unverified / not domain-authenticated.

Objects — Digital Twins for Real-World Products and Assets

ObjectID “Objects” represent physical products or assets with a lifecycle. Each Object contains:

  • Immutable data: attributes that must never change (e.g., manufacturer identity, initial serial reference, model family, genesis info).

  • Mutable data: attributes that can be updated with traceability (e.g., status, location, operational metadata, maintenance fields, assigned agent).

Roles

  • Creator: creates the Object twin and anchors it to a verified domain identity.

  • Agent: performs operational actions during the lifecycle (updates, inspections, handovers).

  • User: reads and verifies the Object, its events, and its validity.

Logical building blocks

An Object can “own” and link to:

  • Events: lifecycle records that anyone can create to record facts (shipment, installation, inspection, incident, service).

  • Counters: structured tracking for repetitive events (cycles, usage counts, refills, check intervals).

  • Components: logical relationships between Objects to describe complex systems (assemblies, plants, machines, fleets).

 

Ownership over time

Each Object can have an Owner, and ownership can change over time to represent sale, custody transfer, leasing, or operational responsibility changes.

 

Object logical states (typical state model)

ObjectID supports a state machine concept that can be customized per use case. A common logical model includes:

  • Draft: created but not finalized for operational use (internal staging).

  • Active: operational and expected to receive events/updates.

  • Suspended: temporarily inactive (maintenance hold, investigation, missing asset).

  • Retired: end-of-life; no longer expected to be updated except for archival notes.

  • Revoked / Invalidated: explicitly flagged as untrusted (e.g., fraud, wrong domain linkage, policy breach).

  • Transferred: not a terminal state, but a recorded transition when Owner changes.

These states can be driven by Creator/Agent actions and by policy rules defined at integration level (e.g., “only Creator can move Draft → Active”, “Owner can request Suspended”, etc.).

 

Integrations for Objects

ObjectID Objects are designed to sit between operational systems and field reality.

Common integration patterns:

  • ERP / PLM / MES

    • Create Object twins at manufacturing time

    • Sync immutable manufacturing identifiers (batch, SKU, internal reference)

    • Push operational status changes from MES

  • WMS / Logistics / Supply Chain

    • Record shipping, handover, proof-of-delivery as Events

    • Track custody and ownership changes

    • Generate QR labels for packaging and pallets

  • IoT / Edge devices (sensors, gateways)

    • Devices submit periodic Events (telemetry summaries, alarms, compliance checks)

    • Counters track cycles/hours/usage (predictive maintenance)

    • Gateways sign data or forward it via authenticated agents

  • Mobile apps (operators, inspectors, customers)

    • QR/NFC scan → resolve twin → verify validity → show lifecycle timeline

    • Field actions create Events with metadata and attachments stored off-chain (hash anchored in twin)

  • Compliance / QA systems

    • Inspection events, audit trails, certificates linked as Document twins

    • Controlled workflows for regulated environments

Documents — Digital Twins for Digital Documents

ObjectID “Documents” are digital twins for files (PDFs, contracts, manuals, certificates, reports). The twin tracks the entire lifecycle and the hash of each version—making it possible to prove a document’s originality and integrity over time.

This is useful to guarantee originality because it enables:

  • Cryptographic integrity: each version is anchored by its hash, so any change (even a single byte) produces a different fingerprint and is immediately detectable.

  • Provenance (who created it): the Creator identity is recorded and can be domain-verified, preventing “fake originals” issued under unrelated or spoofed domains.

  • Version authenticity: you can prove which exact version is the current one (and which are superseded), avoiding confusion from multiple circulating copies.

  • Immutable audit trail: every step (draft, edits, approvals, publication, revocation) is recorded in a tamper-evident way, enabling independent verification.

  • Non-repudiation support: approvals and publications are tied to identities and timestamps, so stakeholders can’t credibly deny actions after the fact.

  • Offline-to-online verification: QR/NFC links to the twin URL allow quick checks on printed or exported copies, comparing the file hash to the official recorded one.

In practice: the “original” is the version whose hash is recorded as Approved/Published by a valid, domain-linked Creator, and any distributed copy can be tested against that reference.

Roles and workflow

  • Creator: creates the Document twin and initializes the workflow.

  • Editors: can update the document by publishing a new version hash (multiple Editors supported).

  • Approvers: approve a given version (multiple Approvers supported).

  • Publisher: marks an approved version as public/official.

Document logical states (typical state model)

A robust default lifecycle:

  • Draft: initial version; editable.

  • In Review: submitted for approval.

  • Approved: accepted by required approvers for a specific hash/version.

  • Published: declared official/public (often tied to a specific immutable approved hash).

  • Revoked: document is withdrawn (error, fraud, legal withdrawal) while keeping audit trace.

Crucially: the system preserves cycles (Draft → Review → Approved → back to Draft) and records them immutably.

Ownership over time

Each Document may have an Owner that can change over time (e.g., assignment between departments, transfer between organizations, escrow/repository handover).

Integrations for Documents

Documents typically integrate with repositories and signature/approval tooling.

Common integration patterns:

  • DMS / SharePoint / Google Drive / S3 / IPFS

    • Store files off-chain

    • Anchor each version via hash in the Document twin

    • Keep verifiable integrity even if storage changes provider

  • e-Signature / approval platforms

    • Use Document state transitions to orchestrate who must approve what

    • Record approval outcomes on-chain and link to signed artifacts off-chain

    • Support multi-approver workflows

  • Enterprise workflows (BPM / ticketing)

    • Trigger “In Review” when a process step completes

    • Auto-create new Draft on change requests

    • Link audit events to incident/change management systems

  • Public verification portals

    • Published documents can be verified via URL + hash

    • QR codes on printed documents enable instant authenticity checks

Technical integration surfaces (overview)

Depending on deployment, ObjectID can be integrated via:

  • Smart contract calls (direct integration with the ObjectID package on the network)

  • Higher-level REST APIs (for system integrators who prefer business-level endpoints)

  • Event ingestion pipelines (webhooks, gateways, batch import from ERP/MES)

  • Front-end widgets (QR verify, timeline viewer, status badges)

The typical design is: off-chain storage for large files / rich content, and on-chain anchoring for identity, roles, state transitions, hashes, and audit trail.

Why this approach works

  • Tamper-evident lifecycle history (events, counters, versions, approvals)

  • Domain-authenticated issuance (prevents “lookalike” twins under fake domains)

  • Interoperable verification (URL-based resolution + standard domain linkage)

  • Separation of concerns: data storage can evolve, while integrity and provenance remain verifiable