Behind the Reviewer: A Knowledge Base of Engineering Checks

Every engineering review starts the same way. A calculation on one side, the documents it has to answer to on the other: the design basis, the applicable standard, the reference report. A senior engineer reads across all of them and confirms the numbers hold.

CalcTree's AI reviewer already reads a calculation against the documents you put in front of it and flags what does not line up. The limit was always context. It worked from what was on the page, and little else. The standard sitting in a folder, the design basis from the last revision, the precedent from a similar job last year: none of it was in reach unless you fetched it and handed it over, every time.

CalcTree's knowledge base closes that gap.

What the knowledge base actually is

It is simpler than it sounds. You upload your files (standards, design bases, project documents, reference reports) into a shared workspace. CalcTree indexes them into a searchable index that the AI features read natively. From then on, the reviewer is not limited to the single page in front of it. It can search across everything the workspace holds and pull the relevant passage when it needs it.

The useful consequence is that the workspace compounds. Every document you add widens what the AI can draw on, so the reviewer gets better grounded as the team's library grows, with nobody re-supplying the same references on every job. The work you put in once keeps paying back.

It is also the private, sanctioned version of a habit engineers already have. Pasting a standard into a public chatbot raises real questions about where your documents end up, which we got into in Can engineers upload standards to ChatGPT?. A workspace index keeps your references inside your workspace and puts them to work there. It is the practical form of the argument that standards belong in the workflow, not just in PDFs.

Upload your review logic, not just your references

References are not the only thing worth putting in the workspace. You can also add your own review rule sets and guides: the checks your team runs, the things you always look for, the way you expect a calculation to be presented and justified. Written down as a guide and added to the knowledge base, that becomes review logic the reviewer applies to the page.

In effect you are not only giving the AI the standard to check against. You are giving it your method for checking, and it follows it. Capture more of that method and the review reflects how your team actually works, rather than a generic once-over. That is the shift that matters: a filing cabinet stores what your team knows, this puts that knowledge to work.

Because that logic is managed in the workspace, it is governed and versioned like the rest of your work. You can see which version of which rule ran on a given job, improve a rule once, and have every review that uses it improve with it. A review method stops being something locked in one senior engineer's head and becomes something the team owns.

Why grounding matters for a review

A review is only as good as what it is checked against. An AI working from general training can sound right and be wrong on the specific clause that matters. An AI working from your indexed documents answers from the actual text you gave it, and can point back to what it drew on. That is the difference between a plausible opinion and a finding you can stand behind.

Three things follow. The review is grounded in your documents rather than a general impression of them. Each flag can be traced to the passage behind it. And coverage improves over time as the index fills out, instead of resetting to zero on every project.

How it works in practice

Five steps, most of which you only do once.

Load your references into the workspace

Upload the documents a reviewer would otherwise go hunting for: design codes and standards, your own company design guides, project specifications, datasheets and manufacturer data, and the calc packs from past jobs worth keeping as precedent. CalcTree indexes them into a searchable index that every AI feature in the workspace can read. They are shared across the team and stay inside your workspace, available to everyone who needs them and not pasted into a public chatbot. When a standard is reissued, add the new revision and the workspace works from the version you gave it.

Add your review rules and guides

A reference tells the reviewer what the rules are. A guide tells it how you want them applied. Capture the checklist your senior engineers carry in their heads: the things you always verify, the conventions your calcs and drawings follow, the acceptance thresholds that matter, the way a result has to be justified before anyone signs it. A guide might say to confirm every partial factor against the governing code and flag any set to 1.0 without a stated reason, or to reject a result that cites no clause. Added to the knowledge base, that becomes review logic the reviewer applies on every job, so two reviewers, or the same reviewer on a tired Friday, reach the same answer.

Add the work to review

The thing you are reviewing lives as a page in CalcTree: a calculation built in CalcTree, or a document like an inspection report or a design check. You can also connect the third-party software your team already uses, the analysis models and spreadsheets, and create the review in CalcTree from there. Either way, drop the job-specific documents next to it, the design basis for this project, the relevant site, load or inspection report. The reviewer treats both the page and the wider workspace index as context, so it sees the specific job and your general method at the same time.

Run the review

The reviewer reads across the work on the page, the documents beside it, the indexed references, and your review rules, then flags what does not line up: an input with no source, a factor that contradicts the governing code, a result or finding presented without the justification your guide asks for. Each flag cites what it drew on, the clause or the rule behind it, so you are not taking the AI's word for anything. You can interrogate any finding and ask why it was raised.

Produce the report

The findings assemble into a review record: what was checked, against which reference, what was found, how serious it is, and what needs a human decision. It carries the trail back to the sources, so it stands up in an audit rather than reading as one person's opinion. It is a by-product of the review, not a separate evening of formatting. And when the inputs change and the calculation is re-run, the review runs again against the same rules.

Shaped around how your team works

No two teams review the same way. The codes you work to, the conventions you follow, the failures that have bitten you before and now sit on every checklist: that is the knowledge that makes a review yours. The knowledge base is where it lives, and getting it in well is something we would rather do with you than leave you to work out alone.

So we start by understanding how your business actually runs: what you review, against which standards, where the bottlenecks are, and what a finished, signed review has to contain for your clients and your auditors. Then we help you set the workspace up around that, the references that matter to you, the review rules that encode your method, and the report your work needs to produce. What you end up with fits your requirements rather than a generic shape you have to bend yourself to.

And because the underlying job is the same wherever you look, documents checked against a standard and against each other, the approach is not limited to one discipline. It travels to wherever an expert reads work against a code and signs it off.

The engineer still signs

A knowledge base does not move the responsibility. The reviewer does the first pass and flags what needs eyes. The responsible engineer reviews those flags, makes the calls, and signs off. The standard is applied as written and is not reinterpreted. That human verification is not a limitation we are working around. It is the point. The aim is to give the expert a faster, better grounded first pass, so their judgement lands where it matters.

This is just the beginning

Everything above is the foundation, not the destination. The direction is reviews that run themselves: automated review guardians that watch your work and your data and check it continuously, rather than waiting for someone to press go. More of the standards and reference data engineers rely on will live natively in the platform, so less of it has to be brought in by hand. And the knowledge base will learn from use. As reviews are completed, their outcomes and findings feed back into it, so each review makes the next one sharper. The method is not just written down once. It compounds.

If your team spends more time fetching and cross-referencing documents than you would like, we would like to show you what a reviewer with a knowledge base looks like on your standards and your work. Book a call.