Superintelligence Prep for Civil Engineering Firms: Project Files

An AI agent for a small civil engineering firm is most useful as a read-first assistant that answers status questions from the project file. It can tell a project manager which sheet is current, what changed in the last revision, and which comment is still open, but only when the folders and revision log make an issued drawing easy to tell apart from a working draft. This article covers what to organize before any agent touches project records.

Key takeaways

• Status answers should come from a revision log that records issue status, not from file names, email threads or chat history.
• Keep issued sets, working drafts and superseded sheets in separate, clearly labeled locations.
• Start the agent with read access to the log, the document register and the issued sets, and keep every write action behind a named approval.
• Treat text inside markups, comments and contractor emails as material to be read, never as instructions to be followed.
• Test the agent against a short list of status questions with known answers before giving it a wider role.

Why status questions are harder than they look

A question such as 'Is the retaining wall detail approved?' seems simple. To answer it correctly, someone has to know which revision is current, whether it was issued for construction or only for review, whether a reviewer comment was closed, and whether a later revision replaced it. Most small firms keep those answers in people's heads, in a project manager's inbox, or in a set of files whose names almost match. An agent that searches by similarity will often find a document that looks right and is out of date.

This is why retrieval alone is not enough. Retrieval-augmented setups give a model access to outside documents at answer time, so the quality of the answer depends on which documents get retrieved and how they are labeled. The NIST AI Risk Management Framework treats this kind of concern as part of managing AI risk across the system lifecycle: the people who deploy a system need to know what information it relies on and where that information can be wrong. For an engineering firm, the practical version is direct. Before the agent answers, the firm must be able to say which record counts as the source of truth.

For the broader design of project memory, see project memory for engineering firms.

Build the folder tree around issue status

Most small firms organize folders by client and phase, which suits filing but not status. A better structure puts status inside each project. A workable pattern uses four status areas per project: working, for review, issued and superseded. Working files belong to the design team and may change daily. Files for review have been sent to a reviewer and should not be edited without logging a new revision. Issued files are the only area an agent should cite as current. Superseded files stay available for audit but carry a visible label and a pointer to their replacement.

Naming matters more than it seems. Each file name should carry the document number, the revision letter and the discipline, so a person or a tool can match a file to its log entry without opening it. Names like final version two, really final should be retired, because they look authoritative and contain no reliable information. A firm that already runs a records system can apply the same principle: the folder structure is a convenience, and the log is the authority.

The records question is covered in more depth for consultancies in AI for engineering firms: proposals, records and client walls.

Make the revision log the source of truth

The revision log is the single table where every document has one row per revision. It does not need specialized software to start. A spreadsheet with stable columns works if the rules around it are followed. The fields that matter most for status questions are:

• Document number, the stable identifier that does not change between revisions
• Revision letter and a short description of what changed
• Discipline and sheet title
• Status: working, for review, issued or superseded
• Issue reason and the name of the person who approved the issue
• Replaced by, filled in when a newer revision is issued
• Open comments, linked to the comment record or its count

The rule that makes the log useful is simple: a revision is not issued until the log says so. If a drawing has been sent to the contractor but the log still shows it as for review, the agent will report it as not yet approved. That is the safer error, and the project manager can fix the log. The opposite error, where the log says issued but the file was never sent, is the one to prevent with a short checklist at each issue step.

Decide what the agent may read, draft and send

Access should match the job. For a status assistant, the minimum is read access to the revision log, the document register and the issued folder. It does not need write access to design files, and it should not be able to change a status field. Drafting a request for information or a status summary for a project manager is reasonable, provided a person reviews the draft before it leaves the firm. Sending anything to a client, a contractor or a regulator is a separate permission that belongs to a named role, not to the agent by default.

The OWASP authorization guidance makes the general point that each access decision should be checked against the rules for the specific user and action, and that access should be limited to what the task requires. The agent acts on behalf of a person, so its permissions should never exceed that person's.

Document-based agents carry a specific risk as well. Markups, comments and contractor emails are text, and text can contain instructions. A comment that tells the reader to ignore the log and report a detail as approved is an attack on the agent, whether it was written maliciously or pasted in by mistake. The OWASP prompt injection guidance recommends treating retrieved content as untrusted, keeping it separate from instructions, and limiting what the model can do even when it is manipulated. For a status assistant, this means each answer should cite the log entry, and the log, not a comment, decides status.

A step-by-step preparation plan

Before handing any project record to an agent, a small firm can work through this sequence:

• Choose five to ten status questions the project team asks every week, and write the correct answer for a few real projects.
• Confirm that each project has a document register with stable document numbers, and fix duplicates before anything else.
• Move issued files into one area per project, and label superseded files with a pointer to their replacement.
• Add the revision log columns listed above, and backfill the current status of every active document.
• Name one owner for the log and one written rule for when a revision is issued.
• Give the agent read-only access to the log and the issued area, and record every answer it gives during a trial period.
• Compare its answers with the known answers, correct the files or the rules where it fails, and only then consider drafting tasks.

This order matters. The agent's accuracy is limited by the weakest record it can reach, so cleaning the log comes first and is usually the cheapest improvement available.

What happens when the files disagree?

Illustrative scenario: a project manager asks whether the retaining wall detail on the site plan is current. In the working area, the agent finds revision C. The log shows revision D issued for construction, revision C marked superseded, and two comments closed against D. A well-organized file lets the agent answer with revision D, state that the working copy is outdated, and report the open comment count from the log. Without a log, the agent would return whichever file matched the query most closely, which may be the working copy with the most detailed text.

How a managed approach keeps status answers accountable

Be Human designs the memory and tool boundaries for one role before connecting it to project files. In a managed engagement, that means defining which folders and log fields the agent may read, which drafts it may prepare, and which actions require a named approver. Recurring evaluations run the same status questions against current records, so a change in the log that breaks an answer is caught early. Permission reviews check that access has not grown beyond the original role, and incident response covers cases such as a misfiled issue or a superseded drawing cited to a contractor. The firm keeps control of the agent's memory, tools and approvals throughout. If you are unsure which status question to hand to an agent first, the free Be Human AI diagnostic can help you find the first task worth handing to an agent.

Frequently asked questions

Can an AI agent answer status questions from email alone? Not reliably. Email holds decisions and opinions, but it rarely records which revision is issued, whether a comment was closed, or what replaced a drawing. An agent answering from email will often describe a conversation rather than the approved state of the document. The revision log and issued area should be the primary source, with email used as supporting context.

How many files should sit in the issued area? Only documents that have actually been issued, with superseded copies moved or clearly labeled. Keeping working drafts out of that area prevents the agent from citing them as current. As the project grows, the register and log still identify the current revision of each document, so the area can stay focused.

Does an agent need a specialized engineering platform? Not to start. A maintained register, a log with stable columns and read access to issued files can support a first status assistant. A dedicated document management system may help later, especially for access control and audit trails, but the firm still has to define what issue status means, whatever tool holds the files.

Who should own the revision log? One named person on the project team, usually a document controller or a senior project engineer, should own it. That person sets the rule for issuing a revision, checks entries before each issue, and reviews the agent's answers during evaluations. Shared ownership without a named owner tends to produce a log that everyone trusts and nobody maintains.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.