# Process modeling conventions

These are authoring recipes, not additional public MCP tools. Read process/scenario with the MCP and use the native authoring UI or a separately reviewed scoped adapter for writes.

Digital Thread names express the cross-functional journey, such as Change Management or Electronic Design. Each has a real ordered multi-step process, such as Controlled Change to Released Configuration or Electronic Design to Controlled Handoff. Avoid a one-step wrapper that adds a repeated breadcrumb layer. Link canonical solution/process fingerprints and IDs; a matching display name is not identity. Value Streams organize the value flow, solutions realize capabilities, and lower-level processes implement steps. Mark proposed threads/processes Draft until reviewed.

For human-style BPMN use short task labels, nominal 100x80 tasks, 36x36 events, 50x50 gateways and Arial12. Keep related tasks on a common baseline, flows left to right, orthogonal branches and rework below. Do not make the main flow snake back across the page. Put explanatory sentences in compact external BPMN text annotations with proper associations. Compare in the consuming renderer at equivalent zoom; fit-to-view scale can make equal fonts appear different.

Preserve XML IDs, namespace declarations, native extensions, incoming/outgoing links, software/capability bindings and parent-child diagram overrides when changing DI geometry. Native postBpmn requires the owned edit lock, nonempty XML and SVG and complete child overrides. BPMN flow elements precede artifacts per schema. Some native L1 validators reject optional bioc DI color extensions accepted at L0. Only remove an optional extension after identifying that validation failure. Do not strip semantic extensions. Preserve realizeSolution canonical namespace/prefix and native empty state attributes where the information parser requires them.

Scenarios have ordered steps plus separate metadata/status; saving description alone does not store ordered bindings. Reconcile native ordered steps and referenced process IDs. Information Models need actual entities, attributes and relationships, not descriptions masquerading as associations. Release the native model lock after successful or failed edits. Examples in documentation are proposals, not product certification.