The Boundaries of Structure
Minimum viable context and the danger of ontology bloat
Part X: The Boundaries of Structure
Over-modeling is as dangerous as under-modeling.
One of the most common failure modes for Operating Context Systems is ontology bloat: the gradual accumulation of artifact types, relationship types, and properties until the model becomes too complex to maintain and too rigid to adapt.
There's a tempting logic that more structure is always better. This is wrong. Every artifact type added to the model is a maintenance obligation. Every relationship type creates complexity in how the graph is queried and maintained. Every property added to an anchor artifact is a field that someone (or some agent) needs to keep current.
Structure should earn its place. The test is whether the artifact type, relationship, or property is necessary for a decision or insight that matters. If it isn't driving anything, it's just overhead.
| Question to Ask | If Yes | If No |
|---|---|---|
| Is this type of thing referenced repeatedly across decisions and plans? | Make it a first-class artifact | Leave it as a tag or attribute |
| Is the information too important to live in unstructured documents? | Structure it | Leave it as a document |
| Is there a clear owner for keeping this accurate over time? | Add it to the model | Don't model it yet |
| Will this go stale quickly without active maintenance? | Build a decay mechanism before adding it | Proceed with standard maintenance |
The right frame is "minimum viable context": not the smallest possible operating model, but the smallest one sufficient to support the planning and decision-making the organization actually needs to do.