The BRD Sections

A Logic Context BRD is organized into up to 11 sections, each written by a dedicated specialist agent. Sections can be enabled, disabled, renamed, and reordered per project, and at least one must remain enabled. This page describes what each section covers, how requirements are identified and traced, and the special treatment business processes receive.

The 11 sections

Section	Written by	What it documents
Business Processes	BusinessProcessesAgent	Each process as a business definition, plus process-mining insights (personas, paths, decision points, bottlenecks)
Logic Flows	WorkflowsAgent	System workflows: what each flow does, its inputs, outputs, and behavior
Logic Blocks	BusinessRulesAgent	Business rules: validations, validation sets, formulas, decision tables, and decision trees
Schedules	SchedulesAgent	Scheduled jobs: what runs, when, and why
Events Definitions	EventsAgent	The events the system defines and their properties
Event Handlers	EventHandlersAgent	How events are wired to the flows that respond to them
Configurations	ConfigurationsAgent	Configuration values and what they control
Localized Resources	LocalizationAgent	Localized strings and the languages they cover
Service Connections	IntegrationsAgent	External integrations and the services they reach
Recipes	RecipesAgent	Logic recipes: the entity hooks that run business logic on data changes
Data Model	DataModelAgent	The entities and fields the project uses

Each Flowon artifact type maps to a familiar business-documentation concept, so the reader sees requirements, not platform internals. Field names, codes, and configuration keys are translated into plain language in the prose, while the underlying identifiers remain available through traceability.

Process-mining insights

The Business Processes section goes beyond a static description. For every process, Logic Context derives and documents:

• Personas: the roles and actors involved in the process.
• Happy path: the intended, shortest successful route through the process.
• Critical path: the longest or slowest route.
• Decision points: where the process branches and on what conditions.
• Automation coverage: how much of the process runs automatically.
• Bottleneck risks: the stages most likely to slow the process down.

These insights are what turn a process description into something a stakeholder can reason about and improve.

Traceability

Every generated requirement carries a traceability block that links it back to the exact Flowon artifact it was derived from, including the original artifact name. This is what makes the document auditable: a reviewer can follow any requirement in the BRD straight to the configuration that produced it. The document reads in business language, but nothing in it is disconnected from the real system.

The artifact ID scheme

Every documented artifact receives a stable identifier, so requirements can be referenced precisely across the document and in review. The default prefixes are:

Family	Prefix		Family	Prefix
Business processes	BP		Schedules	SJ
Logic flows	WF		Events	EV
Validations	BR		Event handlers	EH
Validation sets	VS		Configurations	CF
Formulas	CA		Localized resources	LR
Decision tables	DT		Integrations	IN
Decision trees	DX		Data model entities	DE

Each prefix is overridable per project (letters, digits, and hyphens, up to 8 characters), so the document can follow your own numbering conventions. The synthesis step also computes cross-section dependency references, so the document reads as one connected whole rather than eleven disconnected lists.