AI for an Excavation Company: Locate Tickets and Daily Job Logs

An AI agent can help an excavation company by tracking locate tickets, matching each ticket to a job site and crew, and drafting a daily job log from field notes, dispatch messages and photos. The useful starting point is records and reminders, not equipment control. Anything that authorizes digging, changes a utility marking or stops work should stay with a named person who approves it.

Key takeaways

• A locate ticket is the record that shows when digging was authorized, so track its status, validity window and marked areas in one place.
• Daily job logs are most useful when they capture field facts in a fixed structure instead of a narrative summary.
• Start with an agent that reads, drafts and reminds, and give it write access only to low-risk fields.
• Safety-critical actions, including releasing a dig, confirming marks or overriding a stop, stay behind human approval.
• Judge the setup by whether a supervisor can trace every entry to a source and to a person who confirmed it.

Why locate tickets are the first record to get right

In many regions, a crew requests utility locates through a one-call or call-before-you-dig service before breaking ground. Marks fade, get disturbed and expire, and most locate requests carry a validity window after which the crew must request again. The rules differ by jurisdiction, so check the local requirements with your legal or safety advisor before you write them into any process. What matters operationally is that the ticket is findable at the moment someone needs it. A ticket that lives only in an office inbox or on a foreman's phone is effectively missing when a crew is standing at the edge of a trench.

For each active ticket, keep these fields in one record: the ticket number, the site address and a plain description of the dig area, the date requested, the validity window, the utilities notified, the marking status and the date it was last confirmed, the name of the person who confirmed the marks on site, open responses or disputes, and the trigger that calls for a new locate, such as a changed scope or a crew moving to an unmarked area.

A setup sequence you can run without replacing your current tools

You do not need new software to begin. A shared spreadsheet or your existing project system is enough for the first version, provided each row follows the same fields. Work through the setup in this order:

• Create one record per locate ticket with the fields above, and use the same field names across every project.
• Assign one owner per active ticket, usually the foreman or project lead, and write that name into the record.
• Set reminders for expiration dates and for re-locate triggers, sent to the owner and to the office coordinator.
• Connect the agent to read the ticket records and the job log, but do not let it submit new locate requests on its own.
• Have the agent draft each daily log entry from the crew's check-in notes, then require the foreman to confirm or correct it before it is saved.
• Review exceptions every week: expired tickets, work recorded outside a marked area, and utility responses still open.

The sequence matters more than the tool. Once the fields are stable, moving them into a dedicated system is a much smaller task.

What a daily job log needs to hold up later

A daily log should answer the questions a project manager, an inspector or an insurer will ask weeks later: who was on site, what equipment ran, which ticket covered the work, which areas were excavated, what marks were confirmed and by whom, whether any utility was struck or nearly struck, what inspections happened, what materials arrived, and what changed in the schedule. Photos are most useful when they carry a location and a time. Structured fields beat prose because they can be compared from one day to the next, and a missing field is easy to spot.

Illustrative scenario: A crew installs a conduit run on a Tuesday. The foreman's voice note says the marks on the north side look fine. The agent drafts the entry with the ticket referenced and the marks recorded as foreman observation, not re-verified. The foreman edits the draft to add that the south end marks are faded and a re-locate was requested. The agent then flags the open re-locate request for the office on Wednesday morning. The agent does not mark the ticket as cleared, and the south end stays off the schedule until a person records a new confirmation.

Where agents help and where they must wait for a person

Give the agent read access to ticket records and job logs. Give it write access only to drafts, reminders and flags. Keep authority over safety status with people. A simple decision guide makes these boundaries concrete:

• Drafting a log entry from field notes: the agent may draft, and a person confirms before it is saved.
• Sending a reminder about an expiring ticket: the agent may send it to the named owner.
• Requesting a new locate: the agent drafts the request, and a person submits it.
• Confirming marks, closing a ticket or recording a utility response as resolved: a person does this, and the record shows who and when.
• Authorizing a dig, changing a stop-work status or accepting a missing mark: a person decides, and the agent has no permission to do it.

Agents also read text that others write, including utility responses, emailed updates and notes pasted from a message thread. Any of that text can contain instructions that a careless or hostile sender might intend to steer the agent. Keep the agent's instructions separate from the data it reads, and do not let content inside a document change what the agent is allowed to do. The OWASP guidance on prompt injection prevention covers this class of risk in detail.

How Be Human approaches this as a managed operation

Be Human designs the agent around one defined role, such as a locate and log coordinator for a named project team. The first engagement specifies the memory the agent may read, such as ticket records, log templates and the crew roster, the tools it may call, the approval boundaries described above, and one observable success criterion, for example that every active ticket has a named owner and a recorded validity date. Managed operations then cover monitoring of exceptions, periodic permission review when crews or systems change, maintenance of the connections to your existing tools, and controlled changes to the agent's instructions, each logged with a reason and an approver.

Teams that run timed logs for other kinds of field work face a similar structure. The approach used for post orders and incident logs applies directly to daily excavation logs, and the way engineering firms keep project memory is a useful reference for keeping field records traceable.

Why safety-critical actions stay behind human approval as agents improve

An agent becoming more capable does not change who is accountable for a utility strike or an unauthorized dig. Accountability should set the limit on authority. Agents also fail in a particular way that matters here: their summaries read confidently even when the underlying note was ambiguous. A foreman reading a clean draft may assume the marks were checked when they were only described.

Two engineering habits help. The first is least privilege, which the OWASP authorization guidance describes as denying access by default and granting only what a specific task needs. The second is observability: every agent action should leave a trace that shows what data it used, what it produced, and who approved it. The OpenTelemetry concepts primer describes the logs, traces and metrics that make such a trail possible. When you consider giving an agent more authority, do it through a written review of the permissions and the evidence, not because the underlying model performs better on a general test. The NIST AI Risk Management Framework offers a useful vocabulary for that review.

How do you know the setup is working?

Do not measure success by how much the agent writes. Measure whether the records can be trusted. Check that every active ticket has a named owner and a validity date, that every log entry has a source and a confirming person, that exceptions are reviewed on the agreed schedule, and that no safety status changed without a recorded human approval. Run the same review on a sample of past entries each month, comparing the draft with the final version, so you can see where the agent needs clearer instructions or narrower permissions. If the setup is sound, the questions you ask in the field should be answered faster and with less doubt.

To find the first task worth handing to an agent in your firm, take the free Be Human AI diagnostic.

Frequently asked questions

Do I need new software before I can use an AI agent for locate tickets? No. A shared spreadsheet or your current project system can hold the ticket fields and the daily log for a first version. The important step is agreeing on one set of fields and one owner for each active ticket. Dedicated tools can come later, once the records are stable and you know what you need them to do.

Can the agent request locates from the one-call service for my crews? It can draft the request, but a person should submit it. Locate requests carry legal and operational consequences, and the person submitting should know the scope of the dig and the area to be marked. Keeping submission with a named person also makes the record clearer when a dispute comes up later.

What should happen if the agent makes a mistake in a daily log? A person should catch it during the confirmation step, which is why that step is required before the entry is saved. Each entry should keep its source notes and the editing history, so the correction is visible. If the same kind of error repeats, review the agent's instructions and its permissions, and narrow them before adding anything new.

How does this fit with safety requirements I already follow? The setup supports your safety process rather than replacing it. The agent keeps records, reminders and exceptions in order, while your competent persons, site supervisors and required procedures keep making the decisions that carry safety weight. Check local rules and your insurer's requirements before changing any procedure, and treat the agent's output as a record to verify, not as a determination.

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