How independent companies operate as one company without becoming one
Somewhere on a data center campus right now, a superintendent is walking to a gate to accept a truck of #57 stone.
He works for one general contractor. The project is run by a joint venture between his employer and a competitor. The purchase order was issued by the joint venture. The quarry that loaded the truck is a third company. The driver works for a fourth, or for himself. The person who will approve the invoice works for the partner firm, under authority that comes from a document neither of their HR systems has ever read.
He accepts the load. It works. It has worked this way for decades.
But consider what actually happened. A person employed by Company A committed Company B to a payment, on behalf of an entity that is neither, based on a measurement taken by Company C, delivered by Company D. Each of those companies runs capable software. Several of those systems can authenticate external users, federate identity, and maintain rigorous audit trails. What none of them had was an authoritative account of the arrangement itself: who, on this project, was permitted to do what, on whose authority, subject to which limits.
The gap was closed by a signature on a paper ticket and by the fact that everyone involved is a professional who knows what they are doing.
That is the construction industry’s most impressive and least examined achievement. Independent companies temporarily operate as one organization without actually becoming one company.
The question worth asking is not how they manage it. It is what happens to the arrangement when the people holding it together are no longer the only ones acting.
Part One: The Temporary Organization
Large projects are frequently delivered through joint ventures. Two or more contractors form a project-specific organization, appoint a managing partner, and run the work through a combined structure covering procurement, project controls, accounting, safety, logistics, and subcontractor management.
An airport redevelopment program may run through such a venture for the better part of a decade. Stadiums have been delivered by four-party ventures. For contractors operating at that scale, standing up temporary multi-company organizations is a routine part of doing business, not an edge case.
The legal structure is well developed. Lawyers have spent a century learning how to write these arrangements: governance, delegations of authority, approval thresholds, allocation of responsibility, joint and several liability to the owner. The temporary organization exists, and it is real enough to sue.
What it does not have is a machine-readable counterpart.
Employees typically remain employed by their parent companies while holding roles and authority inside the venture. Which produces a distinction no corporate system is the natural home for: the difference between corporate identity and project identity.
A person works for Company A. On this project, they are a Project Executive for the joint venture, with approval authority up to a threshold, on a specific work package, for the duration of the program. On a different venture, the same person has read access and nothing more. On a third, no standing at all.
Written as a predicate, authority on these projects looks like:
Company + Project + Role + Contract + Work Package + Location + Approval Authority + Time
A modern identity platform can be configured to represent a good deal of that. Custom attributes, groups, attribute-based policies, entitlement management, conditional access: the capability exists.
The problem is not capability. It is authority.
Company A’s directory is authoritative about one thing: who works for Company A. It is not the source of the joint venture’s authority; the joint venture agreement is. And Company B has no particular reason to treat a competitor’s directory as authoritative proof that someone may bind an entity they jointly own.
That is a trust-boundary problem, and no amount of configuration on either side resolves it.
Part Two: Temporary Authority
There are three ways the industry closes the gap today, and every large project uses all three at once.
Guest accounts. The most common. One party’s system becomes the project system and everyone else is invited in. Modern construction platforms make this generous: the license holder pays, and subcontractors, vendors, designers, and owners are added at little or no cost. It works well. It is also, structurally, a tenancy. As an invited collaborator you work inside another company’s system, under a permission model that company defines, with an audit log it controls and a subscription it can end. Useful for that project. Worth nothing on the next one.
Copies. Where two companies each run their own environment, data is shared across accounts as linked copies. A real improvement over emailing files. It also shares artifacts rather than authority: a document crosses the boundary, and the question of who was permitted to approve it does not travel with it.
People. Everything the first two cannot cover. Someone re-keys a ticket into a second system. Someone emails a PDF. Someone requests a login to a partner’s environment that outlives the reason it was issued by several years. A superintendent who technically has access to a partner’s cost data does not open it, because he knows the joint venture agreement says otherwise even though the permission model does not.
That third mechanism does far more work than anyone accounts for. And it rests on a property of human beings that has never had to be written down.
People habitually use less access than they are granted.
Over-permissioning has been survivable for thirty years because the gap between granted access and exercised access is filled by professional judgment. The permission model was never the real rule. It was an approximation, and everyone knew it.
What changes
Every partner on these projects is now deploying AI against project data. Scheduling, cost analysis, document review, procurement, field reporting. This is budgeted, not speculative.
Software does not use less access than it is granted.
The point does not depend on anything controversial about how models work. It does not require training on project data, or long-term retention, or any particular vendor’s data policy. It requires only the difference in scale between a person and a process.
A person with technically excessive access to a partner’s document repository will never open thirty thousand files. There is no time and no reason. An agent with the same access can search, correlate, summarize, extract, and transmit across all thirty thousand in minutes, as a byproduct of doing exactly what it was asked to do. It has no way to know that the joint venture agreement draws a line the access control list does not.
The compensating control was never technical. It was social. Agents remove it.
And it runs in both directions, which is the part that should concern a managing partner. When the project ends you can revoke a partner’s people from a shared environment. What their systems extracted while the arrangement was live has already left, and de-provisioning is not a remedy for something that was copied.
Part Three: Verifiable Authority
The missing object is not identity. Everyone involved has identity, several times over.
There are three distinct assertions on these projects, and today only the first has a real home:
Identity. This is Jane Smith, and she works for Ashcroft Constructors. Issued by her employer, which is genuinely authoritative about it.
Authority. Jane Smith is authorized by this joint venture to accept aggregate deliveries against PO 83721, on work package WP-3200, up to 40 tons per load, through December 31. Issued by the venture, because the venture is what granted it.
Evidence. Jane exercised that authority at 10:43 this morning, on these facts, and here is proof any party can check.
Different assertions, from different authorities, and the second and third have no natural home in anyone’s corporate systems.
An alternative starts by making the temporary organization a real participant rather than a folder inside somebody’s tenant.
The project organization becomes an issuer. The joint venture gets its own cryptographic identity. It can sign. The approval matrix from the venture agreement (thresholds, delegations, who may commit what) is encoded once and signed by both parents. That signature is what makes later determinations binding on both, and it is the root of trust for everyone downstream.
Worth being precise about this: trust is not eliminated. A supplier still has to trust something. But it now trusts one explicit, verifiable thing (the venture’s identity and the governance both parents signed) rather than implicitly trusting a dozen separate tenancies it has no visibility into.
Employment and authority separate. Each parent continues to issue employment credentials from its own directory. Nothing changes internally. The venture separately issues a grant: this person, this role, this work package, this threshold, this site boundary, this date range, conditioned on a valid employment credential from a member firm.
Two credentials, from two authorities, composed at the moment of use. Neither is sufficient alone.
The guest accounts do not disappear. Procore, the ERP, the scheduling tool, the field app: those remain, and people keep logging into them. What changes is that the guest account stops being the source of authority and becomes what it should have been all along: an interface with application permissions. The underlying assertion, this person is authorized by this venture to approve this class of transaction on this package until this date, exists independently of every one of them, and applications consume it rather than each reconstructing it from scratch.
Facts are attested by whoever knows them. The quarry signs the certified weight at the scale, before the truck moves. The mill signs the heat. The fabricator signs the piece and the welder qualifications. The equipment manufacturer’s technician signs the startup, from the field, at the moment of startup. The third-party inspector, who works for the owner, signs the acceptance. Each attestation is issued by the party that actually observed the thing, not transcribed later by whoever is assembling the turnover package.
Downstream decisions compose upstream facts. Release to erect the next tier requires accepted connection credentials below it. Release to functional testing requires the startup attestation and the pre-functional sign-off. Approval of an invoice requires signed acceptances for the loads it bills. These become evaluations over held credentials rather than someone’s recollection in a meeting.
Which means revocation propagates. When a field weld fails inspection, the acceptance credential is revoked, and every downstream authority that depended on it re-evaluates. The crew about to load above that bay finds out because the authority is gone, not because someone remembered to send an email.
Every determination produces a receipt each party holds. This may be the most consequential piece, and it is easy to skip past.
Today the record of a transaction lives in the application that facilitated it, and in that application’s audit log. Access to the record is access to the application. In a temporary organization, that is a structural problem, because the organization eventually disappears and the application subscription ends with it.
In the alternative, the signed determination goes simultaneously to the venture, the supplier, and each parent company. Each holds its own copy. Each can verify the others without trusting them.
Ten years later, nobody has to ask a former partner for their own history.
Why ten years later matters
Joint ventures dissolve. Liability does not.
Statutes of repose in most states run roughly eight to ten years past substantial completion. So years after the entity is wound up, after the partners are competing again, a claim can arrive requiring someone to reconstruct who had authority to accept and approve what, on a specific date, on a specific work package.
That evidence is distributed across a common data environment, an ERP, a procurement tool, a ticketing platform, and a field app. Several belong to the former partner. Some sit under subscriptions that lapsed at closeout. The audit trail belongs to whoever held the tenancy, which means, in a dispute between two parties, it belongs to one of them.
On publicly funded work the same structure carries additional weight. Demonstrating that a certified disadvantaged business enterprise performed a commercially useful function means assembling evidence across company lines about who was on site, whose equipment, whose supervision. Certified payroll requirements mean collecting and vouching for weekly records produced by firms you do not employ. Domestic content requirements mean tracing material from mill through fabricator through erector into the record handed to the agency.
In each case a contractor represents to a public owner facts it learned from someone else. Where those representations support certifications or payment requests, unreliable cross-company records stop being merely administrative. Depending on the facts, inaccurate certifications can create meaningful contractual, regulatory, and False Claims Act exposure, and the underlying evidence is other people’s paperwork.
The same shape, elsewhere on the project
None of this is specific to aggregate, or to joint ventures.
Steel erection runs it: mill, fabricator, detailer, erector, special inspection agency, engineer of record, building official. Eight or more independent companies in a sequential chain, where a subcontractor cannot proceed until parties it does not employ have signed off on work it performed. A crane crew is a fixed daily burn whether or not it is picking, and every hour spent confirming an inspection with a company you do not control is that burn producing nothing.
Commissioning runs it more intensely: the owner’s commissioning agent, manufacturers’ field technicians who are the only people authorized to start their own equipment, controls integrators, the load bank vendor, the utility, the authority having jurisdiction. A data center is not accepted when it is built. It is accepted when it is proven, and nearly every signature in that proof comes from a company that does not work for the general contractor.
The common structure is not collaboration. Companies collaborate constantly without needing any of this. The common structure is delegated authority to act: someone at one company can commit, approve, or disburse in a way that binds a combined entity, and a third party outside the arrangement relies on it.
Wherever that is true, the same conditions follow. The arrangement is temporary. Outsiders see one organization. The parties may be competitors, so merging systems is not on the table. And liability outlives the arrangement, so the record has to as well.
What this is not
This does not replace project management platforms. Those systems run the work, and they run it well. Drawings, RFIs, submittals, schedules, cost, field coordination: none of that is the problem described here, and rebuilding it would waste everyone’s time.
The layer described here sits underneath, and answers a narrower question that project management systems are not structured to answer:
Who was permitted to do this, on whose authority, and can a party outside my company verify that without trusting my records?
The legal profession has known how to create temporary organizations for a hundred years. The agreement is signed, the governance is written, the delegations are defined. What has been missing is the version a machine can act on.
For thirty years that gap was closed by asking someone. The answer was good enough, because the people involved knew the rules, applied judgment, and used less access than they had.
That is the part that is ending. Not because the people changed, but because they are no longer the only ones acting.