Keep guidance connected to its evidence
Guide claims can point to admitted sources and projected application facts. Publication checks that those references are meaningful for the application before turning them into public material.
Example — Only explain a connection the application exposes
An integration guide uses the application’s resolved connection facts. A page for an unavailable surface is withheld instead of sending customers toward a feature they cannot use.
For engineers
An engine-authored unit declares the source facts used by its prose. For example, the orientation connects its authored explanation to the application connection projection:
managedPath: 'get-started.md',
unitRef: 'technical-documentation:unit/application-orientation',
sourceRefs: [
'saas-technical-doc:engine-content/application-orientation',
'source:companion-projection:application-connection',
],
This is a selected engine catalogue entry. Source references are not arbitrary repository paths: the manifest admits engine content, curated consumer facts and declared companion projections. Their identities allow derivation to check that requested facts exist and are used consistently.
Let publication resolve the claim
The companion assembles the application’s evidence snapshot, substitutes declared facts and applies the unit’s applicability requirements. Policy may include, redact or suppress with a named reason. Links to material that is not published are reconciled during rendering, rather than left as promises the reader cannot follow.
A valid source reference proves an admitted evidence connection, not the editorial quality of a sentence. Keep confidential provenance out of public publication, avoid treating missing observations as a negative result, and review the final rendered statement after substitutions. An integration-specific observation supports that integration; it does not establish every neighboring capability.