One of the most fundamental and general principles of design.
Let's say you have some entities (eg, objects, references) and you have some attributes of those entities (eg, security, versioning, persistence) which are pervasive (entities with those attributes breed like maggots) and orthogonal (there isn't any entity that could not have those attributes by virtue of being that entity). So what do you do in that case? You build in the attributes into the definition of the entities.
This is as opposed to building the attributes on top of the entities.
Examples
Let's say you've got an object graph. Every reference in that object graph could be a capability (it's orthogonal) and every reference in that object graph should be a capability (it's pervasive). Therefore, build capabilities into the object graph.
Let's say you've got a capability object graph. Every capability in that graph could have the set of standard PermissionFlags (since the standard permission flags are defined solely with respect to the object graph itself) and every capability should have a set of permission flags. Therefore, build permission flags right into capabilities. See BuildSecurityAbstractionsIntoCapabilities for more.
The same with versioning. The same with GarbageCollection.
OrthogonalPersistence. It's not every process / object graph that should be persistent. In fact, if you make the memory manager orthogonally persistent, you create a StrangeLoop in the OS. It's only typical user processes that should be orthogonally persistent. As a consequence, OP shouldn't be built into processes, but it should be built into user processes. (Which turns out to be trivial if you define processes in a sufficiently flexible manner.)
Non-examples
Changesets. Every object in an OS can belong to one or more changesets, but it's not the case that every object is a changeset.
Execution. It's not every object that can accept a thread.
Process ports. It's not every process that should have access to arbitrary other ports.