A feature name can promise more than the sentence beneath it. Put “Exact Grade” on a button and a user may expect a measurement guarantee, even if the documentation describes a planning estimate. Put “Autopilot” on a review tool and the name may imply that a person can step away. Naming is part of setting expectations, especially when software sits near physical work.
This guide helps a team review an earthwork product name before it appears on a demo, proposal, or interface. It offers a practical editorial scorecard, not trademark clearance or a measurement specification. The names and scenarios are illustrative. The goal is to choose language that a superintendent can question and a product owner can explain without retreating into fine print.
Separate the three naming jobs
A company name gives the business an identity. A product name helps a buyer locate an offer. A feature name tells a user what action or information to expect. Those names can share a family resemblance without doing the same work. DirtAI could serve as a company-level identity, while a product beneath it uses a plain description such as haul record review.
Trying to make every feature sound like the company creates unnecessary explanation. A person searching for yesterday’s ticket conflicts should not need to remember which invented assistant handles them. Start by labeling the workflow literally. A more distinctive product name can be evaluated later, once the team agrees on the job and the boundary of the offer.
Write the ordinary sentence first
Before brainstorming names, complete this sentence: “This helps [person] review [information] before [decision].” For example, a proposed tool might help a project engineer review ticket exceptions before the morning meeting. That sentence identifies the user, the material, and the point at which the work becomes useful. It also gives the team a way to reject names that suggest a different job.
If the sentence is hard to complete, the problem may be product scope. A single feature might be attempting to extract documents, estimate quantities, and direct work. Separate those functions before naming them. Otherwise, a short label will conceal disagreements that later surface in training, support, and the customer’s understanding of responsibility.
Look for implied precision
Review words such as exact, perfect, guaranteed, and certain. Then review less obvious signals: a number in the product name, an accuracy badge, or a technical unit used as a brand flourish. Ask what a buyer is likely to infer. A name does not become harmless merely because the team intended it metaphorically.
A planning estimate can be useful without sounding like a final measurement. Names such as “Quantity review” or “Plan comparison” leave room to explain the source and method. Whether those particular names suit a real product depends on what it does, but the pattern is valuable: name the task rather than an unproven result. Reserve precision claims for evidence that actually establishes them in the intended context.
Separate mapping from authority
A map-centered feature may organize location-linked records, compare layers, or display a proposed interpretation. Those functions do not all carry the same authority. The USGS overview of geographic information systems describes systems for geographic information and its analysis. That broad category leaves many different product functions to explain.
For naming, the practical question is whether the label tells a user that a layer is a reference, an estimate, or an approved instruction. “Plan layers” and “Approved grade” would create different expectations. If approval is a real project state, the software should record who established it and where its authority comes from. The name should not supply an approval that the workflow lacks.
Run the superintendent test
Read the candidate name aloud and ask a likely user, “What would you expect this to do?” Do not explain it first. Write down the response. Then show a short demonstration and ask whether the name still fits. This is a small qualitative exercise, not a survey that establishes broad market preference, but it can reveal a serious mismatch quickly.
A useful demonstration includes an unresolved case. Show an unreadable ticket, an outdated reference, or a conflicting identifier. If the name implies that the software resolves everything automatically, that case will expose the gap. A name that survives a difficult example has a stronger connection to the actual product than one that sounds good only above a perfect screenshot.
Use a four-question scorecard
For each candidate, ask whether it identifies a task, implies an unsupported outcome, is easy to distinguish from neighboring features, and remains understandable when spoken. Record a short answer rather than inventing a precise numerical score. The point is to make disagreements visible, not to create a ranking that looks more scientific than the exercise deserves.
Consider the illustrative label “DirtAI Shift Review.” It suggests a review organized around a shift, but the supporting copy would still need to specify which records are included. Compare it with “DirtAI Zero-Rework Engine.” The latter introduces an outcome promise that a name alone cannot support. A team can prefer the first pattern without claiming that it is legally available or commercially proven.
Make the human checkpoint part of the vocabulary
If a model suggests matches, call the state suggested. If a person has checked the result, use a separate reviewed state. Avoid naming both states “verified” merely to simplify the screen. Users need to know whether they are looking at an automated output, a person’s assessment, or an authoritative project instruction.
The NIST AI Risk Management Framework provides a voluntary reference for considering risks around AI systems. For this naming exercise, the practical question is how terminology affects reliance. A confident label can encourage a user to skip a review the product depends on. That makes naming a useful subject for product testing rather than a final decorative step.
Check the name outside the homepage
A name may look clear in a large headline but become confusing in an email subject, an exported report, or a phone conversation. Try it in all three. The report should still identify the product and the relevant project without making a feature sound like a certification. The email should distinguish a request to review from an instruction to act.
Also check neighboring names. If one module is called “Review,” another “Verify,” and a third “Validate,” users may infer a hierarchy the team never intended. Write a one-sentence definition for each and remove labels that differ only in tone. A smaller set of well-defined states is easier to teach than a collection of impressive near-synonyms.
Decide what to carry forward
Choose the candidate that best matches the demonstrated workflow, then document the claims it must not imply. Qualified counsel can handle trademark questions separately; this editorial review does not determine rights. Product evidence still needs its own assessment. Keeping those decisions distinct prevents a favorable naming discussion from being mistaken for approval of the entire offer.
The next step is small: take one existing feature name and ask a field user what it promises. Compare the answer with the software’s actual output and the person responsible for the next decision. If those do not align, revise the name or the product description before polishing the logo. A clear name earns its place by making the work easier to understand.