01
Company
Client, contractor, developer, agency, vendor, or subcontractor
Connected records
The data layer represents business context as related records instead of isolated files or one enormous table. Each record has identity, source, ownership, status, permissions, and history appropriate to its role.
The database, identifiers, relationships, documentation, and business records remain owned by your company. Your team can operate them internally or appoint another authorised provider after handover. The signed engagement confirms the actual hosting, account, licence, and access boundary.
Entity relationships
The company is an organisation; contacts are people; an opportunity or RFQ connects a commercial relationship to a potential project; documents, estimates, communications, costs, and decisions remain related but independently governed.
One company
Multiple contacts, opportunities, and participating roles
One project
Multiple opportunities, document versions, and estimates
One estimate
Multiple cost lines, quotes, revisions, reviews, and approvals
One workflow case
Multiple companies, activities, exceptions, and evidence records
Client, contractor, developer, agency, vendor, or subcontractor
Senders, decision makers, estimators, reviewers, and project contacts
Commercial relationship, invitation, source, dates, and current status
Name, location, type, stage, value range, and delivery context
Versions, scope, cost, adjustments, review, submission, and outcome
Drawings, specifications, addenda, forms, attachments, and current issue
Messages, notes, calls, decisions, assignments, reminders, and approvals
Committed costs, commercial changes, supporting evidence, and authority
Invited parties, quotes, validity, exclusions, attachments, and response state
When work is awarded, the commercial opportunity can become or connect to the delivery project without re-entering the company, contacts, scope, documents, assumptions, and approved submission context.
Record contract
The exact fields depend on the workflow, but each important record needs enough operational context for people, integrations, reporting systems, and approved AI tools to understand and control it.
For example, an RFQ record does not contain only a project name and deadline. It also identifies where the invitation came from, which company and project it belongs to, who owns the decision, which documents are current, whether required information is missing, and what actions are permitted next.
The record becomes useful because its identity, evidence, ownership, authority, and history remain connected.
What you receive
The approved scope determines which deliverables apply and whether they are transferred, exported, documented in place, or retained in a client-controlled provider account.
RFQ record model
Every RFQ should have a unique identifier and retain a link to its original source. The exact fields follow the client’s workflow, but these record groups establish the operating context.
Estimating data model
The model connects scope, cost build-up, commercial adjustments, supporting evidence, review, submission, and outcome while preserving each approved and superseded version.
A new issue records what changed, who prepared and approved it, which documents and quotes supported it, and which version was submitted.
The operating layer preserves access to the original source while turning important identities, relationships, decisions, approvals, and status changes into usable records.
See how sources become verified recordsEvery document receives a durable document ID
Every revision connects to the original document and carries current or superseded state
Documents connect to the relevant project, RFQ, estimate, company, or change order
Emails connect to sender and recipient contact records
Attachments become document records rather than remaining hidden inside messages
Important email decisions become activities, approvals, or status changes
Source links preserve access to the original message, portal record, or file
Workflow control surface
When an opportunity reaches Released, the data layer can activate approved research, verification, document preparation, notifications, or outreach. Every result writes back to the same project and opportunity identifiers, preserving ownership, evidence, exceptions, and history.
A named person approves the controlled state change
Approved sources can enrich missing organization context
Identity and role checks write evidence back to connected contacts
Templates use approved project, opportunity, and company fields
Only approved messages and recipients can move to release
Status, evidence, exceptions, and outcomes retain the same stable IDs
A status change does not grant unlimited authority. Consequential outreach, pricing, contractual commitments, financial changes, document issue, and other client-defined actions remain subject to permissions and human approval gates.
Provider independence
Software, automation providers, and AI models may change. Your business records should not. The handover objective is an environment your internal team or another authorised provider can understand, operate, and extend.
We document the tables, fields, identifiers, relationships, source rules, permissions, workflow events, exports, and agreed recovery and handover procedures. The signed scope confirms actual platform, account, licence, hosting, export, backup, and provider dependencies; it remains the controlling boundary for a specific implementation.
Map the ownership boundary in a BlueprintWhich company, project, document, or estimate is this?
Which source or person controls the current value or state?
What changed, which version applied, and who approved it?