Provenance Identifiers 

Ornatrix records that it produced a file by writing a short provenance identifier into everything it exports. This page describes exactly what that identifier contains, so that studios with pipeline review requirements can audit it rather than take our word for it.

 

What it is 

A single line of ASCII, around a hundred bytes, of a fixed form:

oxpv1:p=oxapp;v=5.1.8;t=1755561600;l=b012446fd030b172;k=1;d=0;m=<32 hexadecimal characters>

The fields, in the order they always appear:

  • p - which product wrote the file: oxapp, oxmax, oxmaya, oxc4d or oxue.
  • v - the product version.
  • t - when the file was written, as seconds since the Unix epoch in UTC, rounded down to the hour.
  • l - a one way hash of your licence identifier, salted and truncated to 64 bits.
  • k - which generation of Ephere's key produced the authentication code.
  • d - whether a Demonstration build wrote the file.
  • m - an authentication code covering all of the above.
 

What it does not contain 

The identifier carries no personal information. It never contains your name, your email address, your company, your computer or user name, any file path from your machine, the contents of your scene, or your licence identifier itself. The only licence related value is the hash in the l field, which cannot be reversed without key material held by Ephere.

The timestamp is rounded down to the hour rather than written at full resolution. That is deliberate: it keeps the identifier useful for establishing roughly when a file was made, while removing the per file precision that would let anyone holding a set of files correlate them into one studio's output by comparing exact write times.

 

Where it is written 

  • Groom files, .oxg.yaml and .oxz - a top level ornatrixProvenance key in the document header.
  • Alembic, .abc - an ornatrixProvenance property on the archive's top object.
  • USD - ornatrixProvenance in the layer's custom data, and again in the exported curves prim's custom data so that it survives the layer being referenced into another stage.
  • PNG images written by the App - an XMP packet, in a standard uncompressed iTXt chunk.

In every case the identifier is metadata. It does not alter geometry, strand shapes, vertex positions, texture pixels, or any other data your scene depends on. A file with the identifier removed renders identically to one that still has it.

The authentication code covers every other field, so the identifier cannot be edited, copied onto another file, or made to name a different licence without the change being detectable.

 

Why it exists 

Ephere's licence terms prohibit using Ornatrix or its output to train machine learning models. The identifier is what allows Ephere to establish that a given file was produced with Ornatrix when investigating a suspected breach of those terms. The licence agreement also prohibits removing, altering or obscuring it.

 

Can it be turned off 

No. There is no setting, environment variable or command line switch which disables it. An identifier that could be switched off would tell us nothing about exactly the files where it matters most.

The format is documented here precisely so that it can be reviewed instead. If your pipeline has a requirement this page does not address, please contact us.

 

Related 

Missing Something? Let us know if this page needs more information about the topic.