Article

Your project history shows how jobs were run

By TrustPast

Published October 21, 2026 · Updated October 22, 2026

A trade company’s project history is every job it ran, from the first bid to the last warranty call. It sits in folders, in old software, in email and on paper in the back office. Most owners see it as storage they’re required to keep. This page settles which part of it shows how the work was done, what sets the price, what can stop a deal, and what stays behind.

Why buyers want it

A work order is one visit. A project is the whole arc. The bid, the schedule, the daily logs, the inspections, the punch list, the closeout packet, and the warranty calls that came in two years later.

The job files and work orders page goes through a single job. This page is about the line through a project, and between projects. The same address coming back in year three, year seven and year twelve.

Polyshares pays to license records like these to train AI models. It says, on its data licensing page, what it is paying for: “The value is not in volume. It is in reasoning that was captured while the work happened.” As we read it, a project file is reasoning in the order it happened. Nobody wrote the daily log knowing how the job would end. Which files hold that reasoning in each trade, and which hold only names and payments, is on what data buyers want from a trade business.

What sits in a project file

Here is what a trade company’s project history usually holds, as our own description:

the bid, its versions, and the bids that were lost;
the scope letter and the contract terms the work was priced on;
the schedule, and every time it moved;
the daily logs: who was on site, what got done, what held things up;
the inspection requests, the results, and the re-inspections;
the change orders and the emails that settled them;
the punch list, item by item, and the date each was closed;
the closeout packet: warranties, product sheets, as-built notes, the sign-off;
the warranty callbacks, and what each one found.

Most of these are short. Fifteen years of them is how a company learned to run a job.

The bid shows how an estimate became a job

Every project starts as a number. The bid is the company’s first guess at what the work will take.

Here is a worked example, as our own description. A bid goes out for a re-pipe on a two-storey house. The first version assumes open access from the basement. The second version, sent after a walk-through, adds drywall repair on the second floor. The customer asks for a third version without the repair. The company sends it, with a note that patching is excluded. The job is won on version three.

The invoice shows the final price. The bid folder shows how it was built, what the walk-through changed, and what was left out. Polyshares says, on its answer page about what data is worth, that one thing moving the number up is “Visible disagreement and correction.” As we read it, a bid folder is that: a price corrected, version by version, with the reason for each one.

The schedule and the daily log

The schedule is the plan. The daily log is what happened instead.

A daily log is plain. Crew of four on site at seven. Rain from eleven, tarped the opening, sent two home. Supplier shorted the order by two bundles. Inspector rescheduled to Thursday. Each line is a decision made with what the crew knew that morning.

Read across a project, the logs show why a three-week job took five. Read across a hundred, they show which delays the company learned to plan for. As our own reading, the schedule says when. The log says why it moved.

Inspections and the second visit

An inspection is a stranger checking the work. Here is what an inspection trail usually holds, as our own description. The request and the date it was booked. The result. The correction notice, if there was one, in the inspector’s words. The crew’s note on what they changed. The re-inspection and the pass.

A failed inspection is a record of a problem found, argued and fixed. Polyshares says, on its data licensing page, that “A support ticket that shows a problem being misdiagnosed, argued over, and finally resolved is worth more than a clean table of finished numbers.” As we read it, a correction notice and the re-inspection after it are that kind of record, written on site instead of in a ticket queue.

The punch list and the closeout packet

The punch list is the last argument on a project. The customer walks the job and writes down what isn’t right. The crew goes back and fixes it, or explains why it’s right as it is.

A scuffed door frame, touched up. A drain the customer thought was slow, tested and left alone, with a note saying why. The punch list shows where the work fell short, and where customers expected more than the contract said.

The closeout packet is the clean version: warranties, product sheets, as-built notes, the sign-off. As our own reading, it ties the project together, but the reasoning sits in the logs and the punch list before it. Polyshares makes the same point about finished work in general, on its answer page about what data is worth: “the finished documents carry conclusions with the reasoning removed.”

Change orders across a whole project

One change order is a single disagreement, settled. The job files page goes through how one reads. A project history adds the pattern.

Here is a worked example, as our own description. A kitchen remodel runs eleven weeks. It has six change orders. Two came from what the demolition found. Three came from the customer changing their mind. One came from a product that went out of stock. Each was priced, pushed back on and settled, mostly over email.

Across years of projects, the change orders show whether the company got better at bidding. The settling often happens in the inbox, which is why the email archives page matters here too. Polyshares says “A thread where two people disagree about a quote and work it out carries judgment that cannot be manufactured.” As we read it, a change order and its thread are that, with a price on the end.

Warranty callbacks and the same address, years later

A project doesn’t end at the sign-off. It ends when the warranty runs out, and sometimes not then.

A leak at a flashing eighteen months on. A fixture that failed in the first winter. Each warranty callback says which project it came from, what the diagnosis was, what it took to fix, and whose fault it was. Next to the original project file, it shows whether the work held.

Then the same address comes back. A company fifteen years in one area returns to the same buildings. The first project is an install. The second is a repair. The third is a replacement of the thing the first project installed. Read in order, that is how a building aged and how one company kept up with it.

What sets the price

Polyshares prices each company after it has read the record. Its terms say: “We look at the record before we price it. We do not pay for something we have not seen.” Three things move the number, in Polyshares’ own words.

Years. Polyshares says, on its home page, that “Depth of operating history and how much visible reasoning the record contains move the number far more than raw volume does.” It also says “The question worth answering is not how many gigabytes exist but how many years of judgment are visible inside them.” A project history is years by nature: the install, the callbacks and the replacement on one address can span fifteen of them.

Reasoning you can see. Polyshares says two records that look alike can be worth very different numbers: “One is ten years of people working problems out in writing; the other is ten years of calendar invitations.” As we read it, a year of daily logs is a lot of visible reasoning in a few lines a day. The closeout binders alone are closer to the calendar invitations.

Not headcount. Polyshares says “The length and texture of the record matter more than headcount or revenue.” A twelve-person contractor with fifteen years of project folders is not behind a larger one with three.

What Polyshares has paid is public. It says typical deals run from $100,000 to $2,000,000 and above (indicative, not an offer). Its case studies page lists four closed deals: a roofing company at $450,000, a general contractor at $300,000, a solar company at $275,000 and a global marketing agency at $110,000 (indicative, not an offer). Each is described as a “Perpetual exclusive license to the operational record. Anonymized before delivery.” Polyshares says “Company names stay confidential,” and it doesn’t publish what each record held. A past deal doesn’t predict an offer. Our estimate is a range from your answers, not an offer.

Worth two minutes to see your range? The estimate asks five questions.

See your estimate

What blocks a deal, and the fix

Four things stop a project history. Each one has a fix, and Polyshares publishes how it handles each.

Drawings, specs and subcontractor prices that belong to someone else

A project done for a general contractor or a property manager may sit under their contract. The drawings and specs may belong to the client. A subcontractor’s pricing may have come to you under a non-disclosure agreement. Polyshares says material held on behalf of a client “cannot be licensed regardless of value, and only the contracts separate the two.” It calls this “the single most common reason a promising record turns out to be unsaleable.”

The fix: sort the projects by contract before anything else. Polyshares says confirming ownership “is the one part that starts with the company, because only you hold your customer contracts.” It also says customer agreements often allow use “in aggregated or de-identified form,” and that a company “should have its own counsel review any license before signing.” What counts as client-owned material, and what an NDA keeps out, is settled there.

Names, addresses and gate codes in the logs

A project file has people in it. That is the first thing owners worry about, and it should be. Here is what sits in a project file that is personal, as our own description:

the customer’s name, and the names of anyone else in the household;
the address, the gate code, the lockbox number;
phone numbers and email addresses;
the payment schedule, the deposit, the cheque copies, the finance paperwork;
notes on someone’s health, written because it changed how the crew worked.

None of that is how the work was done. Polyshares says, on its data handling page, that “Names, emails, phone numbers, account numbers, and addresses are removed or replaced by a specialist PII partner before Polyshares or any buyer sees the record. Roles, timestamps, and the work itself are kept.” So the homeowner becomes a homeowner. The site becomes a site. The foreman becomes a foreman. What the crew did, and when, stays as it was written.

The address is the thread that ties years of visits together. It is also personal data. As we read it, what is kept is that the projects belong to the same place, not where the place is.

Among the things Polyshares says cap a price or kill a deal outright is “Personal information woven through the record in a way that cannot be cleanly stripped.” In a project file, names tend to slip into the daily logs and the emails. The fix: raise it on the call, and don’t scrub the files yourself. Polyshares says identifying fields are stripped “before anything moves,” and that “Handling that is our responsibility rather than yours.”

The software’s export limits

Project files sit in software, and each vendor sets its own export rules. Where the files sit in Google Workspace, Google says the organization-wide export needs a super administrator account “that is at least 30 days old.” It says the export “is available no earlier than 48 hours after you start the export,” typically takes 72 hours and can take up to 14 days. And “Once you click Start export, the process cannot be canceled or stopped within the Google Admin console.”

The fix: you don’t export anything to apply. Polyshares says: “Intake asks for record counts, not files or exports.” Count first. The steps and the limits, quoted from Google, are in our guide to exporting Google Workspace mail, Drive and Chat. Use it after an agreement, with the scope set to what the agreement names.

Missing years, two systems and paper

A switch of software often leaves old logs behind. The early years sit in a filing cabinet, the middle years in a retired system, and only the last five in the current one. An owner who counts only the current tool undercounts the record.

The fix: count every place (below, under what owners overlook), and note the gaps. Polyshares says “The messy working record is the point, not a defect in it.” A gap of two years in the middle is a gap; it is not a reason to count none. A company that is closing loses years fastest, and what a closing company’s records are worth sets out what to keep before the accounts go.

What owners overlook

Where project history lives

Before you look at a range, know where the projects are. As our own advice, count these: the current software and the one before it; the shared drive with a folder per job; the inbox the bids went out from; the crews’ phone photos; the filing cabinet with the paper logs. The crew threads count too, and the chat archives page covers them.

Count the years, not the jobs. Note the gaps too.

What this means for a roofing company

This is our own description of a roofer’s project history, not a list from any buyer.

The inspection report and the bid built from it. The insurance scope and the supplements, round by round. The tear-off log that says what the deck looked like under the old shingles. The change order for rotten sheathing. The final walk and the photos. The workmanship warranty, and the calls under it after the next big storm. Then the same roof, ten or fifteen years later, when the house has a new owner and the company is asked to look again.

What this means for an HVAC company

An HVAC company’s projects are installs and replacements, and the service years in between.

The load calculation and the equipment options in the bid. The permit and the inspection. The startup sheet with the readings on day one. The callbacks in the first summer. Then the maintenance visits, year after year, on the same unit, until the replacement bid comes round again. As our own description, that loop from install to replacement is a project history in one line, and a long-running company has thousands of them.

What this means for a plumbing company

A plumbing company’s projects run from a one-day water heater swap to a full re-pipe that takes weeks.

The bid and its versions. The camera inspection that changed the scope. The rough-in inspection and the final. The change order for what the wall hid. The callback for the fitting that dripped. Then the same address in year five, when the main line goes, and the note that the company flagged it in year one. This is our own description of what a plumber keeps.

What this means for an auto-repair shop

An auto-repair shop’s project is a larger job on one vehicle: an engine, a transmission, a restoration that takes months.

The estimate and the teardown that changed it. The parts on back-order and the delay they caused. The calls with the owner about whether to go on. The comeback, and what the second look found. Then the same vehicle, visit after visit, for years, with the shop’s notes on what it recommended and what got done. As our own description, the vehicle’s history is the record. The owner’s name and card are not.

How a deal works

These are Polyshares’ published steps, in order. The whole sequence, with what can stop each step, is on how a data deal works.

You see your range on our estimate. Five questions, two minutes. It is our estimate, not an offer.
You apply to Polyshares yourself, through the estimate’s link. Polyshares says intake asks for record counts, not files or exports.
Polyshares reads the record and agrees what is in scope. It says: “We look at the record before we price it. An offer comes within one to two weeks, and terms are papered right after.”
You confirm ownership, and your counsel reviews the licence. Polyshares says the licence covers “Defined systems, a defined term, and exclusive by default unless we agree otherwise. Nothing outside that scope is covered.”
You approve and share. Identifying fields are stripped by Polyshares’ PII partner as part of preparing the data. Polyshares says “Listings are published without the company’s name, website, people, or exact locations.”
Polyshares pays “Net 30 to 60 once the data is approved, anonymized, and delivered.”

Polyshares says the cost to the company is “None. No fee, no commission. We pay you.” It also says: “A license is not a sale. The company keeps operating exactly as before, with the same data, the same systems, the same customers.” Your crews keep writing daily logs tomorrow.

Where we fit

We, TrustPast, explain the process and give you a range with our estimate. The estimate is ours, not an offer; Polyshares makes offers. When the estimate names Polyshares, you apply to it yourself. Polyshares pays us a referral fee. You pay us nothing. We never see your project files. Our how it’s safe page says the same in plain words.

Before you apply

Four things to do first, as our own advice:

Find every place a project lives. The software, the old software, the shared drive, the inbox, the filing cabinet. Count the years.
Don’t tidy the folders. Keep the lost bids, the scrawled logs, the failed inspections and the punch lists. They are the reasoning.
Line up the projects with the email and the chat. A change order is often settled in the inbox.
Ask your counsel which projects you did under someone else’s contract, and what your customer terms allow.

Then answer the five questions. If the range is worth your time, apply.

What is never included

Polyshares’ home page says the licence is for “Defined material for a defined term,” and that “It does not cover what you hold on behalf of your own clients.”

Now our advice, which is ours and not Polyshares’:

Customer names, addresses, phone numbers, emails and account numbers. They were never the thing being bought. Under Polyshares’ terms, the PII partner removes them.
Gate codes and lockbox numbers. They are in the logs for the crew, not for anyone else.
Payments. Deposits, cheque copies, card slips, bank details, finance applications. They are not how the work was done. Ask that they stay out of scope before you accept an offer.
Health information. A note that a customer uses a wheelchair or needed a quiet site. It belongs to them. Raise it the same way.
Staff personnel and payroll files. Pay, reviews, injury reports. A daily log can name the crew; the HR folder is not a project record.
Drawings and specs a client owns. They stay out; the blocker above, drawings, specs and subcontractor prices that belong to someone else, says why and what to do.
Subcontractor pricing under an NDA. A sub’s quote sent to you in confidence is theirs to keep confidential. Leave it out unless the agreement says otherwise.

Polyshares says its legal answer page “is not legal advice, and a company should have its own counsel review any license before signing.” That is our advice too. What is licensed is set out in Polyshares’ offer, after it has read an anonymized sample.

TrustPast

Questions and answers

Does the buyer want our customers’ names and what they paid?

No. As we read it, customer names and payments are not what is wanted. Polyshares says names, emails, phone numbers, account numbers and addresses are removed or replaced by a specialist PII partner before Polyshares or any buyer sees the record, and that roles, timestamps and the work itself are kept.

Do we have to send our project files to apply?

No. Polyshares says intake asks for record counts, not files or exports. It says nothing leaves your systems until Polyshares has made an offer and you have accepted it.

Our old projects are a mess of paper, folders and two software systems. Does that count?

Polyshares says “The messy working record is the point, not a defect in it.” As we read it, a project folder with drafts, rejected bids and handwritten logs holds more of the reasoning than a tidy closeout binder does. Count the years in each system and on paper, and note the gaps.

Does the depth of years matter?

Yes. Polyshares says “Depth of operating history and how much visible reasoning the record contains move the number far more than raw volume does.” It also says the length and texture of the record matter more than headcount or revenue. Fifteen years of projects from a small company is a deep record.

Do we keep our project files after a licence?

Yes. Polyshares says a licence is not a sale, and that the company keeps operating exactly as before, with the same data, the same systems and the same customers.

What does it cost us?

Nothing. Polyshares says there is no fee and no commission. Polyshares pays TrustPast a referral fee; you pay us nothing.