ObjectID project was established with a foundational mission: to provide a unique, persistent, and standardized identity for any physical entity. Until now, ObjectID has served as the “DNA” of our data, ensuring that every element within our ecosystem is uniquely recognizable and retrievable.

However, in an increasingly complex digital landscape, static identity is no longer sufficient. It is not enough to simply know what a document is; it is imperative to prove what happened to it, who approved it, and when it became final. Trust relies not just on uniqueness, but on immutable history.

This is where the ObjectID Document Notarization System comes in. This module is not a standalone entity, but the integrity engine that powers the next generation of the ObjectID framework and distributed application.

While ObjectID defines the “Who” (the unique identifier of the asset), the Notarization system defines the “When” and the “How” (the proof of existence and state traceability).

By integrating this system, we transform ObjectID from a simple identification registry into a comprehensive Trust Layer. Every document tagged with an ObjectID can now traverse a certified lifecycle—from draft to immutable notarization—guaranteeing stakeholders three fundamental pillars:

1. Integrity: Mathematical certainty that the data associated with the ObjectID has not been altered by even a single byte.
2. Authenticity: Cryptographic verification of the actors involved (Owners and Signers).
3. Non-Repudiation: A time-stamped proof of existence that stands up to third-party audits.

With this integration, ObjectID becomes the single source of truth for secure document lifecycle management.

Important note: documents (files) are never uploaded onto any private or public server: user need to provide the document to the ObjectID web app to execute and store in the blockchain the document hash. The responsability to keep the document safe remain totaly in charge to the user.

1. Roles (Actors)

These are the entities interacting with the system.

• Creator: the user (DID) who initiate the process creating the document twin on IOTA blockchain.
• Editor: list of users (DIDs) who can update the document hash by providing a new version.
• Approver: list of users (DIDs) who must approve the document.
• Publisher: the user who terminate the process and locks the Document

---

2. Document States (Lifecycle)

The lifecycle of a document, modeled as a Finite State Machine (FSM).

• DRAFT: the document has been uploaded but is still editable. The final hash has not yet been calculated.
• PENDING_APPROVAL: the system is waiting for all Approvers to confirm the document corretness.
• RELEASED: the document has been approved.
• REVOKED: the document has been flagged to be no longer valid. Note: after the APPROVED State the document notarization trace cannot be deleted;

---

3. Workflow

Technical methods enabling state transitions and traceability.

A. Creation

Creator use the CreatedDocument function to create an new Move Object, representing the file on the Blockchain.

Cretor assign roles to the Move Object to enable specific DID to succesfully execute specific tasks.

B. Edit

Any Editor can update the document hash, providing a new file. The edit history is keept in the blockchain.

Any Editor can flag the document in “PENDING_APPROVAL” state or set it back to “DRAFT”.

C. Approval

If the document is in “PENDING_APPROVAL”, any Approval can add an “APPROVED sub-flag. When all aoprovers has approved the document the flag is set to “RELEASED”.