Choose indexing and validation behavior for each branch instead of paying for identical processing everywhere.
An intake branch and a branch serving interactive queries need different preparation. Give each branch a processing profile so storage, indexing, and validation follow its role.
Keep staging lightweight where appropriate. Require the receiving branch's processing rules when proposed changes enter shared work.
Version control covers branch history and review. Commit-time validation explains acceptance checks.
Developer reference
Named presets include storage-only, indexed, indexed-with-search, and full. A profile selects the branch's processing configuration, including core index construction and validation behavior. The preset name is a configuration choice, not a universal performance guarantee.
Stored assertions and derived query structures have different lifecycles. A storage-only branch need not construct the same indexes as a branch prepared for repeated queries. Building fewer structures trades ingestion work for the capabilities and latency available when reading that branch.
A merge cannot assume that the source branch's processing configuration satisfies the destination. Target processing constructs required structures and applies its validation policy, including SHACL checks where configured.
Branch lifecycle class and processing profile are separate decisions. Neither replaces membership, authorization, or purpose-bound access. Choosing a lighter processing profile does not grant access to plaintext or let a caller bypass the receiving branch's acceptance rules.