A tender that keeps
its own record.
Most tendering leaves you with a status field and a folder of emails. XO Bid runs a tender as nine records, one per stage, with the probity controls in the data path rather than in a policy document: anonymity that depends on the stage, one-way locks at comparison and adjudication, and a full freeze once the package is awarded.
Probity you can show afterwards
The questions come later. Who could see what, when. Which scope a price actually answered. Whether anything moved after the award.
Anonymity the stage enforces
Holding the permission to see vendor identity shows you nothing until the tender stage opens it. Identity, submission totals and line returns are each controlled separately, and each needs both the stage and the permission.
A bid answers a specific version
Submissions attach to the issued version they answered, so reissuing scope never slides a vendor price onto work they were never shown.
Awarding freezes the package
Once awarded, the package is frozen. The only ways forward are a reissue, which creates a new linked package, and a supply-chain intake check.
What a recorded tender changes
Vendor identity, submission totals and line returns are each separately controlled, by stage and by permission.
A bid is anchored to the exact issued version it answered, so a reissue cannot move it onto different scope.
An awarded package is frozen. Going further means a reissue, which creates a new linked package.
Issue, compare, adjudicate, award
Each stage is a record rather than a status, which is what makes the sequence reconstructable later.
A tender is nine records, not a status field
Each stage of the tender is its own record. That is what lets you show the sequence afterwards instead of describing it from memory.
- Eleven capabilities separable by roleViewing, issuing, inviting, seeing totals, seeing line returns, seeing identity, locking, adjudicating, recommending and approving
- One transaction per requestEvery request is a single database transaction, and mutating requests take a row lock
- Recommendation and award are decisionsRecorded as decisions on the platform record, not as generic system noise
Anonymity the stage controls, not just permissions
Most systems gate visibility on who you are. XO Bid gates it on who you are and where the tender has got to, and requires both.
- Three controls, three permissionsVendor identity, submission totals and line returns are each separately controlled
- Comparison and adjudication lockBoth stages take a one-way lock rather than relying on convention
- Internal and vendor paths are separatedAn internal user cannot act through a vendor endpoint, and a vendor token cannot act through an internal one
From an estimate, and back to estimating
A tender can be seeded from an estimate, and the award hands its result back to estimating, so the commercial thread is continuous rather than re-keyed.
- Seeded from an estimateA tender package can be created from estimating rather than typed again
- Award hands backThe award produces an output contract that estimating consumes
- Reissue links to its parentA reissue creates a new package linked to the one it came from
Where XO Bid sits
Part of the COMMERCIAL bundle. On the roadmap.
XO Estimo
A tender can be seeded from an estimate, and the award is handed back to estimating as an output contract.
XO Chain
A supply-chain intake check is one of the only two actions that remain available once a package is awarded.
XO Commercial
The award is where the tender stops and commercial control of the package begins.
Frequently asked questions
Can vendors submit bids through the product?
Not today. XO Bid is a buy-side tool: the tender is packaged, issued, compared, adjudicated and awarded inside the product, but vendors do not respond or submit through it and there is no vendor portal.
Who can see which vendor submitted what?
Both the tender stage and the permission have to allow it. Holding the permission to see vendor identity shows nothing until the stage opens it, and identity, totals and line returns are controlled separately.
What happens once a tender is awarded?
The package is frozen. The only actions that remain are a reissue, which creates a new linked package, and a supply-chain intake check.
Does a reissue edit the original tender?
No. A reissue creates a new package linked to its parent, so the original stays as it was.
Are awards signed or policy-governed?
No. We do not claim that issue, recommendation or award are policy-governed, and awards are not cryptographically signed.
A tender you can reconstruct
See how the stages record themselves, and what stays visible to whom.