You develop a core technology and other companies build the plants around it. What you owe them is an engineering document package (the design, the specs, the drawings, the integration requirements) cut against that project's site conditions, codes, and interfaces. The technology is yours. The project belongs to someone else.

Their engineers build on your package. It gets forked per project, worked through a gap analysis against the customer's requirements, revised through submittal cycles you don't set the pace of, and read by an EPC that will hold every inconsistency against you. A folder of files with version numbers can't tell you what moved between what you sent in March and what you're about to send now.

Kord is version control for that package. Every revision goes through a review session with visual diffs, the AI flags the specs still quoting stale values, and transmittals record exactly which revisions went to which project, and when.

This is you if

• Your core technology ships as a package into customer or EPC projects.
• Each deployment re-cuts the design basis against site conditions, codes, and interfaces you don't get to choose.
• Submittal and response cycles run on the customer's calendar, not yours.
• The same process values show up across the design basis, the datasheets, and the integration specs, and drift apart over time.
• When a customer asks what changed since the last issue, the honest answer is 'give me an afternoon with the PDFs.'

How Kord fits

Four parts of Kord carry the package:

• Folder forking - fork the base package per project, with the divergence recorded. Improve the base once; pull it into each active project on purpose, not by copy-paste.
• Visual diffs - see the delta between issues in the native format: marked cells in the datasheet, redlines in the design basis, clouded regions on the drawing.
• Review sessions - internal sign-off pinned to exact revisions before the package leaves the building, so what the customer gets is what you actually approved.
• Transmittals - a record of which document revisions went to which project, and when, for every cycle.

Common questions

We don't build the plant. Where does Kord fit?

Kord versions and reviews your side of it: the package you issue. Fork it per project, review revisions internally with visual diffs, and issue through transmittals that record what went out. The EPC's document control runs their side; Kord makes sure what you hand them is consistent and accounted for.

Our documents end up in the customer's system anyway. Does versioning ours still matter?

That's exactly when it matters. Once the package leaves, the customer's register only tracks status: received, under review, approved. Kord is your record of what each issue actually contained, what changed between issues, and who signed it, which is what you need when a question comes back two submittals later.

Can Kord diff the formats in a typical technology package?

Yes: PDFs including P&IDs and drawings, Excel datasheets and calc sheets, Word design bases, images, and STEP 3D models, each diffed in its native format inside one review session.