The system is designed from interface to backend, however it is built in reverse: from the backend up to the interface. It captures intent to whatever degree it can, whenever we create, develop and record, and it is designed to use this to inform the way everything witihin the system works, right to the core.
Intent is captured by what users of the system do. Some like to begin immediately; discovering things by doing, whereas others like to work on structure first before the content. There is a high work cost to pay for translating to capturing intent when a non-trivial amount of work has been put into uncaptured work; the user must rememeber and generate much of the context in hindsight. This is often seen when committing to version control systems, for example. Because of this, the system aims at picking up as much meta-data as it can while its users work in any capacity; helping its users tease the structure out to whatever degree of focus is present, while not imposing too much structure too soon. This is done primarily by the design and structuring of the tools and processes around making adjustments such that they're more conducive to intent-recording.
If the user provides the meta-content at the same time as the content, it has later benefit in various ways, an example of which is the ability to flexibly transform content because more of its real structure is known. The system can record the intent properly rather than just unintelligently recording the activity and differences. However, the system does not enforce this. It is suggested by recommending users start with a set of defaults that have been designed and constrained to their current use-case, and when more is discovered and they find themselves wanting to change or push against the constraints of the structure, provision is included such that the system connects them to someone capable of adjusting the structure for them in an intent-recording way. This process need only apply until they are comfortable adjusting the system for themselves, to whatever degree they are comfortable with.
As a result of this, changes take place through a certain indirect manner: rather than directly acting on the system, rather when adjusting, we create desciptions of activity. That is, we don't delete a word, we create a word-deletion event description; we don't create a thing, we make a "thing-creation event". Later, the system can activate (or play) these events and the effects will take place.
System authors act in the same way. The more granular this process can become, the more knowledge of intent can be captured, and the greater flexibility for higher-level editing can take place later.
Why go to all the trouble of trying to record intent constantly? Communication. This system is about building 'productions' in such a way that they achieve the aim of their creators. Whether these productions are effective can't be detected if their intent isn't known. Conversely, if this intent is recorded, others can help out with those aims and possibly implement them in better or different ways. One could easily envisage a scenario where the intent and implementation are decoupled: that is, the intent is captured but the implementation isn't. Later the implementation could be filled in by someone who understands how to implement it well.
This collaborative effort is sometimes like open source software development; with volunteered work, but allows everyone to work equally on particular things that they have interest or skill in, paid or not. The more all of us understand the intent of anyone trying to do anything, the better, because we can work from a position of greater intelligence in understanding activity. Thus, collaboration of a greater quality is fostered. Much of this can be automatically recorded by providing particular features to users, and evolving these features over time. In particular, providing meta-tools to users so that they can shape their own intent-capturing and intent-communication experiences.