Most ERPs let any record exist in isolation. A line item with no parent. A component requirement floating on its own. A receipt against a PO that was never approved. The system permits states that should be impossible, and you pay for it later in reconciliation.
An SG Schema does not work that way. Every entity in an SG Schema belongs to an entity group. One entity is the root. Every other entity in that group only exists in relation to the root and is only accessed through the root. That is the rule. SG Engine enforces it.
Here is what that looks like in a real manufacturing operation.
A Sales Order is an entity group
Consider a Sales Order for a furniture buyer. The order has line items: 200 dining tables, 150 chairs, 80 bookshelves. Each line item has a SKU, a quantity, a price.
The Sales Order is the entity root. The line items are its members. You never create a line item without a Sales Order. You never modify a line item without going through the Sales Order. If the Sales Order is canceled, the line items go with it.
Why does this matter? Because it defines the boundary of consistency. When the founder approves a Sales Order, all line items freeze together. You cannot approve line 1 but leave line 2 in draft. The group moves as one unit.
Entity group: Sales Order
Root: The Sales Order itself (SO-4521)
Members: Line items (200 dining tables, 150 chairs, 80 bookshelves)
Consistency rule: All line items share the same approval state
A Job Order is an entity group
When the planner allocates work from a Sales Order, the system creates a Job Order. The Job Order is its own entity group, separate from the Sales Order.
The Job Order has its own members: component requirements. A dining table has 22 components. Each component needs a specific wood species, specific dimensions, specific cubic footage. Those component requirements belong to the Job Order.
Entity group: Job Order
Root: The Job Order itself (JO-1187)
Members: Component requirements (table top: mango 2.5 CFT, legs x4: sheesham 1.8 CFT each, frame: teak 1.2 CFT, drawers x3: oak 3.0 CFT each)
Consistency rule: All components share the same production status
The Job Order does not contain the Sales Order. It references it by ID. "This Job Order was created from SO-4521." That is a reference, not containment. This is a core SG Schema rule: entity groups point at each other by ID only, never by nesting one inside the other.
A Vendor Purchase Order is an entity group
Wood needs to be purchased. The system consolidates requirements across multiple Job Orders and creates a Vendor Purchase Order.
Entity group: Vendor Purchase Order
Root: The Vendor PO itself (VPO-0089)
Members: PO line items (500 CFT mango from Vendor A, 300 CFT teak from Vendor B)
Consistency rule: All line items share the same approval and receipt status
Again, the Vendor PO references the Job Orders it was created from by ID. It does not contain them. If Job Order JO-1187 is modified later, the Vendor PO does not automatically restructure itself. They are separate entity groups with separate lifecycles.
Why entity roots matter for your ERP
Three practical reasons.
1. They define what moves together. When you approve a Sales Order, all its line items approve. When you receive against a Vendor PO, the receipt applies to specific line items within that PO. The boundary is clear. There is no ambiguity about "which things changed."
2. They prevent impossible states. A line item cannot exist without its parent. A component requirement cannot exist without its Job Order. An entity group guarantees that its internal state is always consistent. You cannot have a Job Order with 22 components where 3 of them belong to a different Job Order. The boundary prevents it.
3. They make the system faster and safer. When two people are working on different entity groups (one person receiving material for VPO-0089, another person approving SO-4522), they cannot interfere with each other. The groups are independent. No locks. No conflicts. No "someone else is editing this record."
The full picture for a furniture manufacturer
Here is how the entity groups connect in a real deployment:
Sales Order (root + line items)
references ->
Job Order (root + component requirements)
references ->
Vendor Purchase Order (root + PO line items)
references ->
Material Receipt (root + receipt line items)
references ->
Stage Movement (root + component-level tracking records)
references ->
Quality Check (root + inspection items)
references ->
Dispatch Record (root + dispatch line items)
Each group is independent. Each has its own lifecycle. Each has its own rules. They communicate through events: "Sales Order SO-4521 was approved" is an event that triggers the creation of Job Order JO-1187. The Sales Order does not "contain" the Job Order. It published an event. The production boundary reacted.
This is how SG Engine can run completely different businesses from completely different SG Schemas. The entity group structures are different for every client. A furniture manufacturer has Job Orders with component requirements. An apparel contract manufacturer has Work Orders with ephemeral SKUs. A pharma distributor has Supplier Offers with scheme logic. Different groups. Different members. Same engine.
The practical takeaway
If your current ERP lets you create orphan records, records that exist without a clear parent, or records that can be modified independently when they should move together, you are running into boundary violations. The system allows states that should not exist. That is where data gets inconsistent, reports get wrong, and reconciliation becomes a full-time job.
In an SG Schema-driven system, the boundaries prevent this by design. Not by validation rules bolted on after the fact. By the fundamental structure of how data is organized.
SG Engine models your business as entity groups with clear boundaries. Each entity has a root, its members, and its rules. Consistent by design, not by accident.