Multi-week projects as AI training data: what owners should know

What is long-horizon task data?#

Long-horizon task data is a connected record of work that takes many steps over an extended period, showing the plan, the intermediate decisions, the corrections and the result. A multi-week design project with its scope, schedule, reviews, revisions and closeout is a clear example.

The term comes from AI research on agents, meaning systems that take a series of actions toward a goal rather than answering one question. Agents often struggle when a task stretches across many steps: they lose track of earlier decisions, repeat work or miss dependencies. Records of how experienced professionals handled the same kind of work are scarce, because few organizations keep them in linked form.

Why AI developers want multi-week project records#

AI developers want multi-week project records because they show planning and recovery under real constraints. A single RFI answer shows expertise at one moment. A full project shows how a team sequenced work, moved staff when a deadline slipped, absorbed a client change and still made a submission.

These records also help evaluate agents. Given the early state of a project, a developer can check whether an agent proposes steps that resemble what the professional team actually did, and see where its plan diverges.

For an owner or managing principal, the point is that value sits in continuity. A firm with fewer projects that are complete from proposal to closeout often holds more useful long-horizon data than a firm with many projects scattered across disconnected systems.

Illustrative timeline: one project, linked records at each stage#

Illustrative: the timeline follows a fictional engineering firm's design project for a commercial building renovation, from proposal to closeout. Each stage leaves records in a different system, and a shared project number is what ties them together.

Read across a row and you see one stage. Read down the table and you see the long-horizon task. Licensing value sits in the downward reading, which works only when the links between stages hold.

Checklist: what makes a project usable#

A project is usable as long-horizon task data when someone outside the firm could follow it from start to finish without asking a staff member what happened. The checklist below is a practical test you can apply to a handful of closed projects.

Run the test on recent and older projects separately. The answers usually differ, and the point where the firm adopted a new project or document system often marks the line between usable and unusable history.

• 1Dates on every record, including when a decision was made, not only when a file was saved.
• 2Roles on every action: who proposed, reviewed, approved and changed each item.
• 3Version history for models, calculations and drawing sets, with superseded versions kept.
• 4A shared key, usually the project number, used consistently across systems.
• 5Written rationale at least for scope changes, design changes and review dispositions.
• 6A known outcome: delivered, revised, cancelled or disputed, with the reason.
• 7Coverage from start to finish, or a clear note of which stages are missing.

What breaks the chain#

The chain breaks when decisions leave the systems of record. Email threads that settle a scope change, phone calls that resolve a coordination issue and personal drives holding calculations all leave gaps that later readers cannot fill.

System changes are the other common break. A move from one project accounting system to another, or from a file server to a cloud platform, often keeps current projects and drops history. Before any migration, export closed-project records with their project numbers intact.

Reused or renumbered project numbers cause quieter damage. When a numbering scheme changes, keep a crosswalk from old numbers to new, or records from the same project will look like two unrelated jobs.

Illustrative: in the fictional firm's case above, the managing principal tests the renovation project against the checklist. Proposal, staffing, QA and construction records link cleanly by project number, but the client review stage lives mostly in email. The firm summarizes client decisions into the project record and keeps the project in scope, and it sets aside projects whose client stage cannot be reconstructed.

What owners should check before considering licensing#

Owners should check rights, people and commercial exposure before considering licensing project histories, because a full project touches all three.

Licensing does not transfer the archive. Records are licensed, not sold: the firm keeps ownership and agrees to specific permitted uses, and it can decline any project or record type.

Approval inside the firm matters as well. A managing principal can start the assessment, but the authorized signer for the legal entity approves any license, and partners or lenders may need to consent under the firm's governing documents.

How SourceX approaches project histories#

SourceX scopes project histories by asking first whether the chain holds, using metadata such as the systems involved, the years covered and which stages are recorded. Under the SourceX Enterprise Data Value Framework, a complete project history counts for domain expertise, human-generated signal and data cleanliness, not just scale. Preparation cost and privacy burden rise with every system joined, and they reduce net value.

Projects that proceed follow the SourceX five-step transaction: Supply, Rights, Preparation, Approval and Delivery. The managing principal or another authorized signer approves the scope, and a SourceX Evidence Packet records provenance, licensing rights, permitted use, the privacy record and release authorization for each package.