When a user edits a document, only one document at a time is changed. Multiple users my edit multiple documents at nearly the same time, but for the system most of the documents stay the same, only a number of them is altered..

A document may use values from other documents. This is the case if for excample the Tags Property is referencing tags. It uses the name of the tag documents to render as values for the Tags Property. When a service document lists the systems it requires, then the service document uses the names and maybe further properties of the system documents, to render the values of its properties.

When only one document is changed, the property values of all other documents are calculated and readily available.

When If all projectdoc documents are erased, they can be built rebuilt from scratch, since all information is actually derived from Confluence pages. Some information architectures that seemed sound when used in the one-document-at-a-time context will now show if they can cope with the from-scratch context.

One issue may be that with circular references as property values go wild. References should be pointing in one direction. The projectdoc Toolbox will report circular references accordingly. Sometimes those circular reference first show up in the from-scratch scenario. That is because a value may be available from a existing document, but not if the document needs to be calculated.

References in the body of a document are no problem. This is because they are always rendered at request-time, never stored in Lucene or in a cache. Therefore the rendered text in bodies of those documents cannot be found in searches.

Another issue are dynamic properties. This may be more dramatic than circular references. Users may experience dynamic property issues even in the one-document-at-a-time context, if documents seem to be stale, also known . The property values of such documents may often be considered as as not up-to-date.