Primary Breadth-First Development (PBFD)

• Primary Breadth-First Development (PBFD) is a methodology that models business requirements as a directed acyclic graph and enforces breadth-first progression across UI, business logic, and database layers.
• It employs bitmap encodings and Three-Level Encapsulation (TLE) to efficiently represent hierarchical and many-to-many relationships, reducing storage overhead and join complexity.
• PBFD integrates state-machine based workflows and bounded refinement to facilitate formal verification, ensuring robust, high-performance systems with improved development speed and reliability.

Primary Breadth-First Development (PBFD) is a full-stack software development methodology that models business requirements as a directed acyclic graph (DAG) or n-ary tree and treats breadth-first traversal of that structure as the primary organizing principle of implementation. In its original formulation, PBFD is simultaneously a process model for ordering work across user interface, business logic, and database layers, and a data/architecture pattern that uses bitmap encodings to represent hierarchical and many-to-many relationships in relational storage (Liu, 18 Jan 2025). A later formalization presents PBFD as a graph- and state-machine-based methodology verified with Communicating Sequential Processes (CSP) and Linear Temporal Logic (LTL), and systematizes its hierarchical data layer through Three-Level Encapsulation (TLE) (Liu, 18 Aug 2025).

1. Definition and conceptual position

PBFD is defined as a methodology that “prioritizes BFD, occasionally applying DFD or CDD after developing vertices with similar features within the same level” (Liu, 18 Jan 2025). The term “primary” is therefore procedural rather than merely descriptive: breadth-first progression is the default traversal and scheduling rule, while depth-first and cyclic passes are retained as secondary mechanisms for exceptional cases such as end-to-end demonstrations or requirement-driven revisitation.

The original PBFD paper introduces a family of graph-derived development modes that recast software work as traversal over a dependency structure. DAD is the modeling step that translates business requirements into a DAG; BFD and DFD describe breadth-first and depth-first execution orders over that graph; CDD adds directed iterative revisitation; PDFD privileges depth-first traversal with occasional breadth-first or cyclic steps; PBFD inverts that emphasis by making breadth-first progression the dominant strategy (Liu, 18 Jan 2025).

Term	Characterization
DAD	DAG-based structuring of tasks, features, and dependencies
BFD	All neighboring vertices in the current level before progressing
DFD	Complete all levels of one path before moving to the next
CDD	Directed iterative revisitation with feedback loops
PDFD	DFD as primary, with occasional BFD or CDD
PBFD	BFD as primary, with occasional DFD or CDD

The methodological motivation is explicit. PBFD is presented as a response to full-stack practice that reduces complex systems to basic CRUD over normalized schemas, especially when hierarchical business domains generate repeated rewrites, many joins, junction tables, and front-end/database impedance mismatches. The critique is not that relational design is intrinsically invalid, but that conventional development often converges on what the paper describes as PDFD plus CDD under Agile pressure, producing repeated reopening of earlier modules and effective time complexity near $O(V^2)$ in the number of vertices or tasks $V$ (Liu, 18 Jan 2025).

2. Graph model, traversal semantics, and full-stack workflow

PBFD begins with a graph-theoretic representation of the business problem. Let $G=(V,E)$ be a DAG in which vertices represent business steps, pages, modules, or data elements and directed edges encode dependency order. In the canonical example, a global “visited places” application is modeled as an n-ary tree rooted at continents, with branches such as continent $\rightarrow$ country $\rightarrow$ state or province $\rightarrow$ county $\rightarrow$ city, and with branch depth varying across jurisdictions (Liu, 18 Jan 2025). A level can be written as

$$L_k=\{v\in V \mid \text{distance from root}(v)=k\},$$

and PBFD processes all $v\in L_k$ before descending to $L_{k+1}$.

The distinctive feature is that breadth-first ordering is applied across the whole stack. At a given level, implementation proceeds simultaneously through UI, business logic, and database design. For a continents level, for example, the UI may render checkboxes or dropdowns; the business layer may use a CheckBoxListItem view model plus bitmap computation; the database may provide a Continent lookup table and an IdContinents field in a VisitedLocation record (Liu, 18 Jan 2025). The same pattern is then reused for countries, provinces, states, counties, reasons for visit, and comparable sibling structures.

The original paper describes several invariants that PBFD aims to preserve. “Level-wise consistency” means that sibling vertices at the same level share a common representation pattern, especially a shared bitmap and view-model structure. “Sealed code per level” means that once a level is implemented and tested, subsequent work should reuse rather than fundamentally rewrite it. “Round-trip mapping” means that writes and reads follow the same reversible path: UI $V$0 view model $V$1 bitmap $V$2 database column on write, and the inverse mapping on read (Liu, 18 Jan 2025).

PBFD does not exclude other traversal modes. A temporary DFD pass may be used to complete one end-to-end branch, such as a single country workflow, when stakeholders require a full vertical demo. A CDD pass may revisit earlier vertices as requirements evolve. The defining constraint is that these are localized excursions within a global breadth-first invariant rather than the primary development rhythm (Liu, 18 Jan 2025). This later becomes explicit in the formal PBFD state model, where level progression, refinement, and completion are distinct phases rather than ad hoc interruptions (Liu, 18 Aug 2025).

3. Data architecture: bitmaps, flattened hierarchies, and TLE

PBFD’s best-known architectural feature is its use of bitmaps to encode sibling selections and many-to-many relationships inside relational tables. In the original design, each child option at a level is assigned a power-of-two identifier; selecting multiple children produces a bitmap by bitwise OR. If continents are encoded as Africa $V$3, Antarctica $V$4, Asia $V$5, Australia $V$6, Europe $V$7, North America $V$8, and South America $V$9, then Asia plus North America yields $G=(V,E)$0, and all seven continents yield $G=(V,E)$1 (Liu, 18 Jan 2025).

The accompanying C# example computes a bitmap from a list of CheckBoxListItem objects by initializing an integer to zero and OR-ing in each checked item’s ID. Conceptually, if $G=(V,E)$2 is the set of selected children, the write operation is

$G=(V,E)$3

and membership recovery is based on bitwise AND: $G=(V,E)$4 This allows a single integer column such as IdContinents, IdReasons, IdChinas, or IdUnitedStatess to stand in for a set of child relationships that would otherwise require one or more junction tables (Liu, 18 Jan 2025).

The paper’s schema for the visited-places case uses a wide VisitedLocation table with columns such as IdContinents, IdAfricas, IdAntarcticas, IdAsias, IdChinas, IdUnitedStatess, IdHunans, IdMarylands, IdChangshas, IdHawards, and IdReasons, plus conventional lookup tables such as Continent and Reason (Liu, 18 Jan 2025). The authors describe this as a “flattened n-ary tree,” in which parent columns store bitmap data that represent edges to child columns. Many-to-many relationships are compressed similarly: rather than using a PlaceReason table to link visits and reasons, a single IdReasons bitmap field records all reasons attached to a visit.

A later paper generalizes this storage idiom as Three-Level Encapsulation (TLE) (Liu, 18 Aug 2025). In TLE, each unit spans three consecutive hierarchy levels: the grandparent is represented by the table itself, the parent by column names, and the children by integer bitmasks stored in the cells. The pattern is recursive: a parent at one level can become the grandparent table at the next. The formalization gives a small workflow of LOAD, [READ](https://www.emergentmind.com/topics/reconstruction-and-alignment-of-text-descriptions-read), WRITE, and COMMIT, represented as transitions through states $G=(V,E)$5 to $G=(V,E)$6, and proves constant-time child checks and updates when the number of children $G=(V,E)$7 fits into one machine word $G=(V,E)$8. Specifically, for $G=(V,E)$9, both query and update are $\rightarrow$0; for $\rightarrow$1, they are $\rightarrow$2; and batch processing over all parents is $\rightarrow$3 for bounded branching factor (Liu, 18 Aug 2025).

The data-model claim is therefore stronger than “bitmaps save space.” PBFD asserts a deliberate replacement of foreign-key traversal and junction-table joins with bitwise operations on bounded hierarchical slices, while retaining normalization “when it is necessary and efficient” (Liu, 18 Jan 2025). This is why the method is not equivalent to wholesale denormalization. Core entities such as Person remain conventionally relational in the published examples, while hierarchy-heavy dimensions are compressed (Liu, 18 Jan 2025).

4. State-machine semantics, refinement, and formal verification

The later PBFD paper reframes the methodology as a formally specified workflow over layered dependency graphs (Liu, 18 Aug 2025). Structural entities—schemas, UI flows, APIs, business rules, and related components—form the vertex set $\rightarrow$4, and precedence constraints form the edge set $\rightarrow$5. PBFD introduces both levels and patterns: $\rightarrow$6 identifies nodes at depth $\rightarrow$7, while $\rightarrow$8 denotes the cohesive subset of that level currently being processed.

The control model is a state machine with states $\rightarrow$9, $\rightarrow$0, $\rightarrow$1, $\rightarrow$2, $\rightarrow$3, $\rightarrow$4, and $\rightarrow$5. $\rightarrow$6 initializes the graph. $\rightarrow$7 processes the current pattern at level $\rightarrow$8. $\rightarrow$9 validates that pattern. $\rightarrow$0 resolves depth-oriented continuation, including selection of critical children for the next level. $\rightarrow$1 performs top-down completion. $\rightarrow$2 is error termination when refinement is exhausted. $\rightarrow$3 is successful termination when all nodes are finalized (Liu, 18 Aug 2025).

A central addition is bounded refinement. Validation failure at level $\rightarrow$4 can trigger a backtrack to $\rightarrow$5, the earliest level affected by the failure, rather than causing unrestricted rework. The refinement span is $\rightarrow$6, and each level has a bound $\rightarrow$7 on refinement attempts. This produces an explicitly constrained form of cyclic revisitation, conceptually close to the original PBFD paper’s use of occasional CDD, but now with a formal termination boundary (Liu, 18 Aug 2025).

The paper states several verified properties. Bounded refinement termination is expressed as

$\rightarrow$8

Structural completeness at successful termination is given as

$\rightarrow$9

with additional invariants requiring consistency and satisfied dependencies. The progression rule that deeper levels may be entered only after the current level is validated is also formalized, as is top-down completion from $\rightarrow$0 through $\rightarrow$1 (Liu, 18 Aug 2025).

The verification stack is explicit. PBFD is modeled in CSP, checked with FDR 4.2.7, and analyzed through trace, failures, and failures-divergences refinement. The paper reports System : [deadlock free] and System : [divergence free], as well as 26 state-level assertions for legal parameter combinations. A lexicographic termination argument over the tuple $\rightarrow$2—counting unfinalized nodes, remaining refinement attempts, phase ordinal, and intra-phase progress—supports total correctness by showing that every non-terminal transition strictly decreases a finite well-ordered measure (Liu, 18 Aug 2025). TLE is verified in a parallel manner, including hostile-condition checks and concurrent multi-unit execution, again using failures-divergences refinement (Liu, 18 Aug 2025).

5. Reported empirical performance and industrial deployment

The empirical claims associated with PBFD come from two connected but differently framed reports. The original paper states that over eight years of production deployment for tens of thousands of users, the approach produced zero bugs, development speed improvements of up to twenty times, performance gains of seven to eight times, and storage requirements reduced to one-eleventh relative to traditional methods (Liu, 18 Jan 2025). The later paper recasts the deployment record as zero critical failures between 2016 and 2024 and specifies that these included no deadlocks, no catastrophic data inconsistencies, and no production outages attributable to PBFD’s workflow or data operations (Liu, 18 Aug 2025).

Aspect	Reported result	Source
Production reliability	Zero bugs over eight years for tens of thousands of users	(Liu, 18 Jan 2025)
Production reliability	Zero critical failures from 2016–2024	(Liu, 18 Aug 2025)
Development speed	Up to $\rightarrow$3 faster	(Liu, 18 Jan 2025)
Runtime performance	$\rightarrow$4–$\rightarrow$5 faster	(Liu, 18 Jan 2025)
Storage	Reduced to one-eleventh	(Liu, 18 Jan 2025)
Storage	$\rightarrow$6 reserved-space reduction	(Liu, 18 Aug 2025)

The mechanism proposed for these gains is multi-factorial. The original paper attributes the development-speed advantage to DAG-based planning, breadth-first level sealing, reduced rework, fewer joins and junction tables, compact bitmap encoding, separation of write-optimized operational schema from reporting views, and reduced context switching because developers work across sets of similar features at a common level rather than repeatedly revisiting disparate modules (Liu, 18 Jan 2025). It characterizes traditional development as best-case $\rightarrow$7 and worst-case effective $\rightarrow$8, whereas PBFD is said to achieve $\rightarrow$9 in most cases (Liu, 18 Jan 2025).

The later paper adds more granular observational and quasi-experimental data (Liu, 18 Aug 2025). It reports that a PBFD full-stack implementation required 1 FTE-month, a traditional relational port was estimated at approximately 9 FTE-months for equivalent full stack, and a Salesforce OmniScript effort consumed approximately 20.4 FTE-months over 24 calendar months while remaining incomplete. It also reports a runtime comparison over 46.7 million audit events in which PBFD had median latency of approximately 118 ms versus approximately 881 ms for the traditional method, corresponding to a $$L_k=\{v\in V \mid \text{distance from root}(v)=k\},$$0 ratio, with average latency improvement of about $$L_k=\{v\in V \mid \text{distance from root}(v)=k\},$$1 and identical $$L_k=\{v\in V \mid \text{distance from root}(v)=k\},$$2 latency of 16 ms (Liu, 18 Aug 2025).

The storage comparison is similarly concrete. One controlled schema-level experiment described in the later paper compares a traditional schema of 13 tables and 4.7 million rows with a PBFD/TLE schema of 2 core tables and 170,000 rows per core table. Reserved space is reported as 658,768 KB for the traditional schema and 56,168 KB for the PBFD schema, a reduction of $$L_k=\{v\in V \mid \text{distance from root}(v)=k\},$$3; index size falls from 37,040 KB to 432 KB, and unused space from 5,448 KB to 48 KB (Liu, 18 Aug 2025). These results are presented as the empirical counterpart of the bitmask and TLE complexity analysis.

6. Relation to other methodologies, scope of use, and limitations

PBFD differs from conventional CRUD-centric full-stack development at three coupled levels: modeling, ordering, and storage. Instead of starting from an entity-relationship decomposition and then building CRUD endpoints, it starts from a DAG or n-ary tree of business dependencies. Instead of progressing entity by entity or vertical slice by vertical slice, it proceeds breadth-first across siblings at the same depth. Instead of representing hierarchy-heavy and many-to-many structures primarily through junction tables and join paths, it preferentially encodes bounded child sets as bitmaps inside relational columns (Liu, 18 Jan 2025).

The methodology is also distinct from MVC. The published implementation uses ASP.NET MVC and C#, but MVC is treated as a structural framework rather than the organizing method. PBFD dictates how view models such as CheckBoxListItem are reused across a level, how controllers coordinate bitmap computations, and how database fields align with the breadth-first graph traversal (Liu, 18 Jan 2025). In the later formalization, PBFD becomes even less framework-specific: its defining artifact is the verified graph-and-state-machine protocol rather than any one web stack (Liu, 18 Aug 2025).

The principal internal comparison is with PDFD, or Primary Depth-First Development. PDFD is vertical-slice oriented: it completes one path deeply before broadening. PBFD is horizontal and pattern-oriented: it completes all relevant vertices or patterns at a level before descending. The later paper presents PDFD as advantageous when an end-to-end user journey must be demonstrated early, and PBFD as preferable when architectural stability, cross-layer consistency, and hierarchical data management dominate (Liu, 18 Aug 2025).

The method’s stated zone of strength is relatively clear. PBFD is presented as especially suitable for complex hierarchical forms and workflows, heterogeneous branch structures, write-centric logging and tracking systems, projects with tight deadlines and limited developer resources, and domains in which reporting can be deferred to views built over an operationally compact schema (Liu, 18 Jan 2025). Claims-processing and geospatial visited-places systems are the recurrent case studies (Liu, 18 Jan 2025, Liu, 18 Aug 2025).

The limitations are equally explicit. Complex reporting from the base schema is harder because hierarchy must be reconstructed through views and business-layer DAG knowledge rather than through self-evident foreign-key structure (Liu, 18 Jan 2025). Bitmaps impose cardinality constraints, especially when child sets exceed 32-bit or 64-bit limits, and the later TLE analysis therefore conditions constant-time access on bounded width $$L_k=\{v\in V \mid \text{distance from root}(v)=k\},$$4 (Liu, 18 Aug 2025). PBFD requires disciplined DAG modeling, tolerance for wide tables whose semantics are partly externalized into business logic, and developer familiarity with bit operations, state machines, and formal verification concepts (Liu, 18 Jan 2025, Liu, 18 Aug 2025). The later paper additionally notes a learning curve, limited mainstream tooling, an initial modeling overhead, and reduced suitability for highly dynamic or unstructured domains such as social-graph-like data (Liu, 18 Aug 2025).

A common misconception is that PBFD is simply “bitmaps in SQL.” The published material indicates a broader claim. PBFD is a development methodology in which graph modeling, breadth-first progression, bounded refinement, shared full-stack patterns, and compressed hierarchical representation are intended to reinforce one another. Another misconception is that PBFD rejects relational principles wholesale; the papers explicitly state that normalization and conventional referential structures remain in use where they are necessary and efficient (Liu, 18 Jan 2025). The distinctive proposal is not anti-relationalism, but a selective reallocation of complexity: from repeated join-centric traversal and iterative module rewiring toward graph-first planning, level-wise implementation, and compact bitmask-based hierarchy handling.