Enforce granular permissions: only Administrators can create, edit, or delete Recipes and Nodes; Authors can view and use guided creation without structural edits.
Define Recipe objects with titles, descriptions, and profile/classification metadata.
Add criteria-based links between Nodes to augment navigation beyond parent/child relationships, improving discoverability of related content.
Specify Node criteria (object type, template, profiles, classification) to automatically resolve matching objects. Results update near real time as metadata changes, eliminating manual lists.
Create new objects directly from a Node; the platform pre-fills metadata from Recipe and Node criteria, reducing misclassification and accelerating authoring.
Build ordered trees of Nodes under each Recipe. Nodes represent sections and sub-sections, enabling structured navigation that mirrors publication scaffolds.
Reorder sibling Nodes to control publication sequence. Authors see the curated order read-only, ensuring consistent navigation across teams.
The nodes in the recipe are each defined by a set of search criteria, for example object type, object template, profile and classification metadata. These search criteria can then be matched with one or more object or objects that fit those critera (including a match for the profiles on the recipe object). When a recipe and objects are distributed, the node structure and objects matched for the nodes create a basic navigation for consumers of the content. A node can have: * zero (if the node is on the top level) or one parent nodes * zero or more sibling nodes (sharing the parent node) * zero or more child nodes (which has the node as parent). These relations create the basic navigation for a distributed publication.
Apply Recipe-level profile filters (e.g., product, version, market) that cascade through all Nodes, ensuring only relevant variants appear without repeated configuration.
Track per-Node coverage (matched, created via Recipe, completion vs. required sets) with badges to quickly identify gaps and drive completion.
Prevent cycles, invalid criteria, duplicate ordering, and overly deep hierarchies (soft warning after 8 levels). Ensure consistent, reliable structures.
No description available
No description available
No description available
No description available
No description available
No description available
No description available
No description available
No description available
No description available
Related requirement tasks from other projects
Description Supports DITA authoring formats; DITA-OT implementation pending. Platform Status: partially implemented PPT Status: Partly MVP: Yes Must Have: Priority 1 (A) Notes DITA OT Not implemented yet Format implemented Is your DITA-OT out of the box or configure and customised. Currently authoring in DITA, don't want a different format. Product Owner Notes Not implemented DITA-OT Notes: DITA OT not implemented yet; implemented format; clarify OT configuration; maintain DITA authoring.
View in Azure DevOps →Description Platform Status: supported PPT Status: Yes MVP: Yes Must Have: Priority 1 (A) Use Case Brands, models, audience, VIN or salescodes, ID, any future needs. Current Challenges Metadata setup in current tool is managed by multiple teams and (depending on the data) can be tied to a deployment. Notes by classification metadata and profiles Profiling, classification, domains, metadata Hierarchical structures: Apply content based on taxonomical structure Produt family->Product->Version. Mapping VIN numbers to metadata filters handled externally Given a list of feature codes (w. description) and they map VIN to feature codes.
View in Azure DevOps →Description Platform Status: partially supported PPT Status: Partly MVP: Yes Must Have: Priority 1 (A) Use Case For example selection of conditions to produce manuals with different engine or transmission types, brands, models, etc. Notes this is profiling, we have not discussed variables - Tobias variables are used for marketing terms, differs between brans. How would one variable look like in a title? - Matthew How variables look in a title of an object. Complex conditions, "profile" conditions. NOT: Apply to Sweden & Norway, you are only ever interested in one facet at a time. Faceting: Profile and inline profiling Product Owner Notes Inline profiling and recipes need to be implemented to fully validate functionality
View in Azure DevOps →Description Platform Status: supported PPT Status: Partly MVP: Yes Must Have: Priority 1 (A) Notes Challenge here would be migration Have to use the engineering handling, clunky. Product Owner Notes Recipes need to be implemented.
View in Azure DevOps →Description Platform Status: partially implemented PPT Status: Roadmap MVP: Yes Must Have: Priority 1 (A) Notes What do they want in detail. If we have an object, that has classification metadata, where we publish it needs to receives an id denoting the origin of the topic. In the future potentially include related metadata. For fully dynamic delivery metadata is needed. Possible, applying invisible character to published PDF for metadata tagging Figures get hidden GUIDs on publication
View in Azure DevOps →