This map is part of the deliverable acceptance revisions guide. The guide covers what to inventory before closeout; this page shows where each record sits and how the pieces connect, so a partner can describe coverage accurately in an introduction.
Four systems, four record sets
A typical services firm spreads one deliverable across these systems. Names differ by company; the roles are consistent.
- Project platform. Milestone schedule, due dates, deliverable register, and often submittal or transmittal workflow.
- Document control. Every submitted revision, reviewer comment letters, response matrices, transmittals. This might be a submittal module, a SharePoint library or a file platform such as Egnyte.
- Contract file. Statement of work with numbered acceptance criteria, modifications, and the signed acceptance certificate. On federal work, acceptance is ordinarily evidenced by an acceptance certificate on an inspection or receiving report.
- Finance system. The milestone invoice, the payment released on acceptance and, on defense work, the electronic receiving report or combined invoice filed through Wide Area WorkFlow.
SharePoint
EgnyteThe linking-key table
The evidence asset for this page. Each row is one record class, where it lives, the key it should carry, and who can say whether it does.
| System | Record | Linking key | Owner |
|---|---|---|---|
| Project platform | Milestone and due date | Deliverable ID (for example D4) | Project controls lead |
| Project platform | Transmittal of each submission | Deliverable ID plus revision number | Project manager |
| Document control | Submitted revision file and attachments | Deliverable ID plus revision number | Document controller |
| Document control | Reviewer comment letter or log entry | Revision number plus criterion number | Document controller |
| Document control | Response matrix | Comment number plus revision number | Project manager |
| Contract file | Acceptance criteria | Criterion number plus contract line item | Contracts manager |
| Contract file | Acceptance certificate | Contract line item plus deliverable ID, ideally revision number | Contracts manager |
| Finance system | Milestone invoice and payment | Contract line item | Finance controller |
Read the table by key. The deliverable ID joins platform to document control. The revision number joins comments to the version they criticized. The criterion number joins comments to the contract. The contract line item joins acceptance to payment. A firm whose records carry all four can rebuild a case end to end.
Where joins usually break
Four failure points come up again and again. Ask about each.
Name drift. The platform says "D4" and document control says "Site Assessment Final v2". Someone has to map them by hand, and after a few years nobody remembers which is which.
Comments filed against the deliverable, not the revision. The comment survives, but it no longer says which version it criticized.
Attachments split across revisions. In Procore, a new submittal revision inherits general information and increments the revision number, but attachments are not carried over between revisions. That is sound practice, because each revision keeps its own files, but it means an export of only the latest revision drops the rejected report. The Procore export page covers what that platform can produce.
ProcorePayment detached from acceptance. On defense contracts, invoices and receiving reports go through Wide Area WorkFlow, and for fixed-price services the contracting officer picks either a combined invoice and receiving report or separate documents. If finance kept only the payment confirmation and not the receiving report, the line item that ties payment to a specific accepted deliverable may be missing on the firm's side.
One fully joined case (Illustrative)
A fictional 260-person environmental engineering firm, deliverable D4, a site assessment report under a federal remediation contract. Not a real project or a completed deal. Here is the case as it would appear once every key lines up.
| Order | Record | System | Keys it carries | Joins to |
|---|---|---|---|---|
| 1 | Criterion 3.2: complete sampling results | Contract file | CLIN 0004, criterion 3.2 | Rows 4 and 7 |
| 2 | Milestone D4, due week 14 | Project platform | D4, CLIN 0004 | Rows 3 and 8 |
| 3 | Revision 0, partial results | Document control | D4, Rev 0 | Row 4 |
| 4 | Comment C-07: criterion 3.2 not met | Document control | Rev 0, criterion 3.2, C-07 | Rows 1, 3 and 5 |
| 5 | Response matrix: resample the gaps | Document control | C-07, Rev 1 | Row 6 |
| 6 | Revision 1, complete results | Document control | D4, Rev 1 | Row 7 |
| 7 | Acceptance certificate | Contract file | CLIN 0004, D4, Rev 1 | Row 8 |
| 8 | Milestone invoice released | Finance system | CLIN 0004 | Row 2 |
Every row links to at least one other. Remove the revision number from row 4 and the comment floats; remove the deliverable ID from row 7 and acceptance cannot be tied to a specific report. The step-by-step story of this case, including who decided each step, is in the exception example.
Scoring a client's joins with the program operations director
Go through the eight rows of the linking-key table and mark each yes, partly or no. Then add three facts: how many years of contracts the answers cover, roughly how many deliverables in that period, and whether any system was replaced midway. That is enough for a partner.
Why the joins matter at all is explained in cross-system data value: a record joined to its context says more than the same record alone. Whether a given firm's records are valuable to anyone is decided in SourceX's review and by SourceX's current data needs, never by the partner's scoring. The referral brief template turns the scores into a short note.
Who decides, and what stays unknown
The program operations director knows the systems; the CEO (in an owner-run firm, usually the owner) decides whether to discuss licensing, with the COO and counsel advising. A document controller or platform admin can confirm keys but cannot authorize anything. Client contracts may assign deliverables to the client while the firm keeps its own review logs, so which rows are the firm's to license, what needs de-identification, SourceX's current data needs and any offer stay unknown until SourceX reviews them. Why AI companies pay for data gives the owner background without promising anything.
The firm needs 50+ full-time employees at peak (contractors excluded), documented operating history, rights to license and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 70% of the data is in English. Partners sign the Channel Partner Agreement before submitting; the first valid introduction within the 90-day window is credited when the company submits a verified application.
Next step
Refer a company. No cap on rewards. Default reward on a company's first qualifying transaction: the greater of $50,000 plus 5% and 15% of Actual Supplier Payout, with no cap; further qualifying transactions first agreed within 12 months of the first Closing pay 15%. Eligibility and payment conditions apply, including the USD 100,000 Minimum Transaction, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.
If most rows of a client's map come back yes or partly, register as a partner, check the firm on who qualifies and read the program terms before you send the summary.