Programmable Content

Definition of what it means for content to be programmable.

Copyright and Language can be found in RFC1

Change Process

This document is governed by the Consensus-Oriented Specification System (COSS).


Programmable Content is a data-driven method of storing content designed for automation. It substitutes much of:

  • naming conventions
  • database as data-store for metadata
  • directory-structure dependency

And serves as an alternative for:

  • directory structure convention
  • directory structure schema

Pre-requisites; intelligent content.

See also RFC65 See also Unified Content Strategy

Naming convention

What are the requirements of a naming convention, and why is naming convention so important to begin with?

In most cases, the one requirement can be distilled into one word - metadata.

$ /projects/hulk/shots/1000/

Here, the following metadata is embedded in this file

  • hulk Which project it belongs to
  • 1000 Which shot it belongs to
  • v001 Which version it is
  • marcus Who is to blame
  • ma Format of the file

Accidental mis-placement of this file becomes obvious and, if adhered to, a file could safely be returned to its rightful directory.

# This file is clearly in the wrong place.
$ /projects/hulk/shots/1000/

Let’s refer to this type of integrity as structural integrity; a file is meant for a certain location within a hierarchy. If this file is moved, it could potentially break dependent files from finding it. Remember, in programmable content, a file is a mere component of a bigger picture - few files ever being guaranteed to be self-contained.

A flip-side to this method of achieving structural integrity however is that if a file is mis-named, rather than mis-placed, there isn’t much you can do in order to determine whether the file has in fact been mis-placed or whether it has been mis-named.

# Does this file belong under spiderman, or has it been mis-named?
$ /projects/hulk/shots/1000/

Structural integrity is important and should be sought after, but perhaps there is a better way. Duplicating information in this manner is a closer to a work-around than a solution.

Consider the following hierarchy:

$ /projects/hulk/shots/1000/marcus/

The full path of is shorter, yet retains the same amount of information as in the previous example.

This is the Programmable Content method of managing data.

Database for metadata


$ /projects/<project>/shots/<shot>/private/<user>/<software>

This isn’t necessarily pre-defined anymore.