Enter Ship Data Once, Let It Flow Through Every Calculation Sheet

Making ship data flow from a single entry into every calculation sheet and report takes more than the phrase "central database." You first have to decide what counts as a single object, which system's value is recognized as official, and what each cell in the workbook actually means. The heart of the technology is not storing data — it is writing the contracts between the work processes.

What "enter it once" actually means

Saying that data should be entered only once is easy. But on a ship project, the same piece of equipment carries different values at different stages. Concept design uses an estimated weight from a reference vessel; basic design brings in preliminary vendor data; detail design reflects the confirmed value on the approved drawing. After installation, an actual weighed value or a field change may be added on top.

So entering data once does not mean the value is fixed forever. It means keeping the official value for each stage — and the evidence behind it — in one place, so that every calculation sheet references the right version. The weight calculation sheet may use the design weight, the procurement document the contract weight, and the production plan the actual transport weight. Different values are allowed, but the difference and the ownership must be explicit.

A ship data model starts with relationships, not geometry

Say "central ship model" and most people picture 3D geometry first. Geometry matters, of course. But if the goal is to connect Excel to the way work actually runs, relationships matter more. Which compartment does the equipment sit in, which system does it belong to, which support structure and power supply does it use, which procurement package is it tied to? Which Deck and Frames is the tank between, what fluid does it hold, under which loading conditions is it used?

Express those relationships as an object graph and the same data gets reused across many tasks. Compartment area and volume can flow into painting, insulation, HVAC, fire protection and cost estimating calculations. Equipment weight and position connect to weight control, support structures, transport and lifting plans. Pipe line diameter and material carry through to quantities, procurement, fabrication and test records.

Between Excel and the central model you need a "Workbook Contract"

The most dangerous way to connect Excel to a data model is to knock together a script that pushes values into specific cells. Add one column, copy one sheet, and the link breaks — and nobody can explain who used that cell or why.

Define a Workbook Contract for each calculation sheet instead. It is a contract that states what inputs the sheet requires, what results it produces, and which units and conditions it assumes. Use Named Ranges where you can; where you cannot, store the cell address together with the surrounding labels and the formula dependencies. The contract should cover mandatory inputs, allowable ranges, the meaning of a blank value, the official source, the conversion rules and the calculation version.

Do not try to own every value at the center

The central data layer should direct traffic, not monopolize the data. The vendor-confirmed weight of a piece of equipment can be owned by the procurement or vendor document system, the installed position by the 3D model, the production status by MES or a shop-floor system. The central layer remembers the source of record and the last revision for each property, and delivers it where it is needed.

Splitting ownership by property also lets you handle conflicts more precisely. When the equipment weight in the 3D model differs from the weight on the vendor datasheet, the system must not silently pick one. It should show that "the model says 12.6 t, the vendor says 13.1 t, and procurement owns the record," then propose either a model update or an exception approval.

How a pump weight change actually travels

Take the earlier pump case again, now inside a connected structure. When vendor datasheet Rev.03 is approved, a document parser reads the equipment tag, the weight and the candidate center of gravity. The system computes the difference against the current official value and asks the procurement owner to confirm it. Once approved, the contract weight of `Equipment P-2101` and its supporting document are updated.

Then the impact graph goes to work. The input cell in the weight control sheet, the equipment foundation check, the lifting plan and the lightship weight report are all flagged as candidates for impact. Each calculation is re-run automatically in a sandbox, but the official result is never overwritten on the spot. The delta against the previous revision, the allowable margin, and any errors or warnings are shown to the reviewer — and only approved results enter the project baseline.

Before you need an API, you need standard units and states

Integration projects usually fail technically not because there was no API, but because the meanings did not line up. Estimated, Design, Vendor and Installed Weight are all different weights; coordinate references and sign conventions differ; even the definition of a status value differs between departments. Connect an API without resolving that, and all you have done is let the errors travel faster.

The first schema should be small. Object ID, name, classification, unit, value type, source of record, revision, effective date and confidence status is enough to begin. Do not try to standardize every property up front — define only the values the chosen workflow genuinely needs. Accumulating a glossary and a set of mapping rules as more projects come through is the realistic path.

What a web-based calculation workbench must put on screen

The user interface should mirror the data structure directly. Ship objects and drawings on the left, the same calculation flow as the existing Excel in the middle, and source, changes and review status on the right is a good arrangement. Users can modify the formulas, but every change is kept as a version and compared automatically against the reference case.

The feature that matters is not an AI chat box. It is being able to answer "where did this cell's value come from," "why does this result differ from the previous revision," and "which documents are affected if I approve it" in one or two clicks. AI should take those questions in natural language, traverse the connected data, and let the user open the underlying evidence region and the calculation path for themselves.

A central model is not a data store — it is a path for trust

Connecting ship data to Excel is not a simple auto-fill project. You have to design the meaning of the objects, the stages of each value, the source of record, the calculation contract and the approval procedure together. Once that structure is in place, the Excel a shipyard has accumulated over decades stops being a set of isolated files and becomes a reusable calculation service.

The next article looks at what to hand to AI on top of this — and what not to. Instead of pretending AI will design the ship for you, it deals with the realistic role: connecting the evidence behind a calculation and making sure the impact of a change is never missed.