Business Relationship Domain Model

Architecture Locked

Business Relationship Domain Model

Status: Architecture Locked · 2026-08-09 Depends on: Business Relationship Philosophy (Architecture Locked)

Not an ER diagram, database schema, API, or UI wireframe. Defines what exists conceptually: Relationship, Business Record, Party, Role, Invitation, Agreement, Milestone, Event, Evidence.

One question

What are the objects in a NoFakeBiz business relationship, and how do they connect — without inventing a Marketplace-owned deal graph?

Inherited axioms

ID	Statement
B0	Every on-NFB business relationship exists within a Business Record.
B1	The relationship is real-world / institutional; the Business Record is its NFB container and evidence surface.
B2	Parties participate through Identities and roles, not through Accounts.

A. Static Model

A.1 Relationship


What it is	The real-world / institutional bond between parties
What it is not	A database row, a listing, a chat thread, or an Account pair
On NFB	Represented and evidenced by a Business Record

One Relationship ↔ one primary Business Record for that on-platform engagement.

A.2 Business Record (container)

Business Record
   ├── Parties[]          (Identity + Role)
   ├── Invitations[]
   ├── Timeline           (Events + speech + artifacts)
   ├── Communication      (threads owned by this Record)
   ├── Offers / Documents / Attachments
   ├── Agreement(s)
   ├── Milestones[]
   ├── Evidence[]
   └── Completion / Resolution outcome

Rule
Thread ownership	Context = this Business Record
Events	Named only via the Institutional Event Catalog
Account	May authorize an Identity; is not a Party

A.3 Party

A Party is an Identity participating in a Business Record under one or more Roles.

Field	Meaning
Identity	Business / Professional / Organization / …
Role(s)	What this Identity may do on this Record
Joined via	Invitation / Intent / direct open
Status	invited · active · withdrawn · …

Refusal: Party ≠ Account. Party ≠ bare email as the root.

A.4 Role

Role describes participation capability on a Record (and may align with domain roles such as Carrier / Broker / Shipper — still on Business Identity, not a separate system type).

Roles are not root entities. Identities wear roles.

A.5 Invitation / Intent

Bridge from discovery to Record — not the relationship itself.

Marketplace (or other discovery)
        ↓
Invitation / Intent
        ↓
Business Record         ← relationship begins on NFB

Marketplace may create intent from a listing. Marketplace never owns the Business Record.

A.6 Agreement

Recorded understanding between Parties on a Business Record (terms, scope, acceptance) — evidenced on the timeline. Lives only inside a Business Record.

A Business Record may contain multiple Agreements or amendments over time; the relationship is not replaced when terms change.

A.7 Milestone

A planned or reached point on the relationship timeline (domain-specific). Lives on the Business Record; may emit Events when reached.

A.8 Event

A fact that something happened (Event Catalog). State (“Completed”) ≠ Event (business_record.completed).

A.9 Evidence

Material that supports what happened or was agreed: documents, marked messages, acceptances, files. Lives under the Business Record. Supports Independent Witness posture — not a guarantee of outcome.

Evidence supports a claim, event, agreement, milestone, or outcome; evidence is not itself the truth judgment.

Entity map

Entity	One-line
Relationship	Real-world / institutional bond
Business Record	NFB container + evidence surface
Party	Identity on a Record
Role	Capability of a Party on that Record
Invitation / Intent	Pre-Record bridge from discovery
Agreement	Recorded understanding on the Record
Milestone	Timeline point on the Record
Event	Fact on the Record timeline
Evidence	Supporting material on the Record

B. Dynamic Model

Discovery → relationship

Party discovers counterparty (Marketplace / Search / direct)
Invitation / Intent (optional but common)
Business Record opened — relationship begins on NFB
Parties + Roles attached (Identities)
Timeline starts (Events)

Conduct

Communication · Offers · Agreements · Milestones · Events · Evidence — all on the Record.

Completion / resolution

Completion Events and/or a resolution path. The Record remains as history / evidence surface.

Boundaries

Boundary	Rule
Marketplace	Discovery / Intent only
Account	Access infrastructure — not Party
Corporate Record Book	Company governance — adjacent, not a substitute for bilateral Business Records

Standing refusals

Marketplace-owned “deal” as root object
Account–Account relationship graph
Orphan chat / agreement outside Business Record
Treating the Business Record row as “the relationship” in product language
Private event names outside the Event Catalog

Business Relationship Domain Model