The median SaaS stack uses 14 tools. Each tool stores its own version of the customer. Stripe has a Customer object. HubSpot has a Contact record. Zendesk has a Requester. Intercom has a User. The same human — Alice at Acme Corp — exists as four unlinked rows in four databases with four schemas and four IDs. The relationships between those records do not exist until a human builds them with Zapier. ```typescript import { Noun } from 'digital-objects' export const Contact = Noun('Contact', { name: 'string!', email: 'string?#', stage: 'Lead | Qualified | Customer | Churned | Partner', company: '-> Company.contacts', deals: '<- Deal.contact[]', messages: '<- Message.contact[]', tickets: '<- Ticket.contact[]', subscriptions: '<- Subscription.contact[]', qualify: 'Qualified', }) ``` Two characters define the entire relationship system. `->` is a forward reference: this entity points to that entity. `<-` is a reverse reference: that entity points back. `'-> Company.contacts'` means "this Contact belongs to a Company, and the Company's `contacts` field is the reverse." `'<- Deal.contact[]'` means "Deals point to this Contact via their `contact` field, and this is the collection of all such Deals." The graph is bidirectional by construction. Every forward edge has a reverse. Every relationship is navigable in both directions. No join tables. No foreign key lookups across API boundaries. No Zapier. ## The Integration Boundary Problem In a multi-tool stack, relationships die at integration boundaries. Stripe knows that `cus_LkN8v4xR` has three subscriptions. HubSpot knows that Contact #4,217 has two open deals. But no system knows that the customer with three subscriptions and the contact with two deals is the same person — because Stripe and HubSpot do not share a graph. The workaround is middleware: Zapier syncs HubSpot Contact IDs into Stripe metadata fields. A custom webhook copies Stripe subscription status back to HubSpot. A nightly ETL job reconciles the two into a data warehouse. Three systems, three integration paths, three points of failure. When the Zapier sync breaks — and it will break — the relationship dissolves. The agent looking at the Contact in HubSpot cannot see the Subscription in Stripe without traversing the broken middleware. | Traditional Stack | headless.ly | |---|---| | Contact in HubSpot, Customer in Stripe | One Contact entity in one graph | | Relationship via Zapier webhook | Relationship via `<- Subscription.contact[]` | | Breaks when middleware fails | Structural — the relationship IS the schema | | Agent needs 2 API calls + ID mapping | Agent traverses: `contact.subscriptions` | | Foreign keys across API boundaries | Typed edges within one typed graph | ## Forward and Reverse The two relationship directions serve different questions. **Forward (`->`)** answers "which one?" A Contact belongs to one Company. A Deal is negotiated with one Contact. A Ticket was filed by one Contact. The forward reference is singular — it points to exactly one entity. ```typescript import { Deal } from '@headlessly/crm' const deal = await Deal.get('deal_hN3vK8wTr') deal.contact // -> Contact (singular: who owns this deal?) deal.company // -> Company (singular: which company is this deal with?) ``` **Reverse (`<-`)** answers "which many?" A Company has many Contacts. A Contact has many Deals. A Project has many Issues. The reverse reference is plural — it collects every entity that points back via the forward edge. ```typescript import { Contact } from '@headlessly/crm' const contact = await Contact.get('contact_pR7kW3mNx') contact.deals // <- Deal[] (plural: all deals for this contact) contact.messages // <- Message[] (plural: all messages with this contact) contact.tickets // <- Ticket[] (plural: all support tickets from this contact) contact.subscriptions // <- Subscription[] (plural: all billing subscriptions) ``` One `Contact.get()` call. Four relationship traversals. Four domains — [CRM](https://crm.headless.ly), [Communication](https:/