Start with guides for the behavior you inherit
Reusable guides explain common application behavior such as access, administration and integrations. Application facts adapt those guides so the reader sees the product they are using, rather than an unrelated framework manual.
Example — A guide that knows the application’s name and resources
The portal’s orientation introduces the application and its managed objects, then leads a reader into sign-in, administration or integration guidance.
For engineers
The engine content bundle owns the prose and the stable unit identity. Its opening entry declares both its authored source and the application connection facts it uses:
managedPath: 'get-started.md',
unitRef: 'technical-documentation:unit/application-orientation',
sourceRefs: [
'saas-technical-doc:engine-content/application-orientation',
'source:companion-projection:application-connection',
],
The surrounding engine catalogue supplies the Markdown body, document kind, audiences and relationships. Companion derivation resolves application names, resource descriptions and other admitted facts before rendering. It rejects unresolved fact tokens rather than displaying template placeholders as product documentation.
Publish only the applicable material
Publication policy evaluates whether the application’s resolved capabilities and evidence support a unit. Included pages become the managed site tree; suppressed material does not remain as a broken destination in a reader’s navigation. Missing evidence and observed inactivity are different states and must not be substituted for each other.
Review the derived portal after a product change. Shared authored guides reduce repeated writing, but do not make a custom business workflow self-explanatory. Application-specific terminology and projected resource semantics still need good source specifications, and custom articles need an accepted publication input.