NOS Studio · Public Knowledge Base

Start Here / Canonical Knowledge Guide

Assets, Versions, and Provenance

How NOS can track externally created creative assets, review decisions, versions, and accepted deliverables.

Architecture and research reference · Updated October 12, 2026 · Current features and future proposals are distinguished below.

The work is created wherever the craft requires

NOS is software-agnostic. A designer may work in a graphics application; a filmmaker may use an established editorial and VFX pipeline; a developer may use source control; a composer may use an audio workstation. NOS does not need to own the application in which an asset is made. It needs to preserve the relationships among a deliverable, its Work Card, its governing Commitment, and the approvals that make a version consequential.

Reference, version, submission, acceptance

A useful asset record distinguishes several things. A reference identifies a file or external resource. A version identifies a particular iteration. A submission brings a version into a review process. Acceptance records a decision under the terms governing the work. A later release or handoff can make that accepted output available to dependent work.

These distinctions matter because an animation, sound design, software feature, design asset, or written work may go through many revisions. A project should be able to determine precisely which iteration was accepted and which later assets depended on it.

Revisions and dependent work

Suppose a character rig is approved and then used by an animation team. If the rig changes, downstream work may be affected. NOS's asset lineage research contemplates explicit versions, relationships, and handoffs that can expose this effect without forcing every creative application into one common file format.

An approved version may remain identifiable even when subsequent versions are created. Accepted does not have to mean that every future creative change is impossible; it means the system should not silently rewrite what was reviewed and accepted at that moment.

Three separate architectural layers

NOS describes an application layer for normal collaboration, an artifact layer where assets are held or referenced, and a canonical truth layer for events that must be attributable and resistant to silent rewriting. Large images, animation scenes, audio, video, and source repositories need not be stored directly on-chain. Cryptographic fingerprints, durable references, or signatures can provide evidence of the exact artifact involved in an approved event.

Recording provenance is not equivalent to acquiring copyright. The economic and legal consequences of a version, submission, or acceptance depend on the agreements governing it. NOS is designed to preserve evidence of rights, not to invent rights because a file was uploaded.

Status of the technology

Detailed asset I/O, version-lineage, and cryptographic architecture in the research archive describe intended product capabilities. They should not be interpreted as proof that all are already available in the October 2026 Alpha.

Further reading: Work Cards, Event Spine, Software-Agnostic Production, and Alpha Roadmap.