An environmental project can accumulate a large amount of information before a team agrees on the next question. Sample locations, laboratory reports, site history, and reviewer comments may all describe different parts of the same ground. DirtAI.com could be the public name for software that helps a project team connect those pieces and retain the reasoning behind its review.
This concept is illustrative. It describes a possible information product, not a certified assessment service or an automated cleanup decision. The first customers could be environmental consultancies that need a consistent way to prepare internal reviews across projects while preserving the original evidence.
Start with three connected modules
The first module could be a sample register. It would track the identifiers, collection details, source reports, and status of each record. A useful register would distinguish a planned sample from a collected sample and a received result from a reviewed result. Those differences are easy to flatten in a spreadsheet and difficult to reconstruct later.
The second module could be a report review workspace. A reviewer would see extracted values beside the source page and confirm uncertain associations. The third could be a decision log that connects a question, the evidence considered, the responsible reviewer, and the resulting action. Together, these modules offer a contained product that can be explained without promising automatic site clearance.
Sell to the review owner
The daily user might be a project scientist assembling records. The internal buyer might be a technical director responsible for review quality and consistency. The product needs to serve both: quick navigation for the person preparing the packet and traceable reasoning for the person signing off on an internal interpretation.
A first commercial offer could cover a defined project workspace with a documented export. Pricing design would need customer research, but the unit of value should be understandable. Charging around a project or review team may be easier to discuss than an abstract quantity of AI credits. The customer should know what remains accessible when a project finishes.
Put provenance ahead of the map
A map can help a reviewer navigate a site, but every plotted result should lead back to a record. The proposed product should retain the reported units, method references, qualifiers, dates, and location information available in the source. It should not erase a qualifier to simplify the legend or substitute an inferred coordinate without making that change visible.
The EPA’s quality assurance project plan guidance provides context for planning the quality of environmental information. A software team can use that context to ask better questions about records and review responsibilities. The guidance does not turn a software workspace into an approved project plan or establish that a particular data set is suitable for a decision.
An illustrative review packet
Consider a consultant receiving a revised laboratory report after an initial internal review. One sample identifier has changed and a result carries an additional qualifier. The product would retain the earlier file, associate the revision with it, and show which review notes referenced the superseded version. A reviewer could then decide which conclusions need another look.
The valuable output is a packet that explains what changed and who reviewed it. A colored area on a map alone cannot do that. The original source, the revision relationship, and the decision note should travel together in the export so the next person can follow the project’s history without guessing.
A careful place for AI
AI might assist with document classification, suggested sample matching, or drafting a list of differences between reports. Each suggestion should be labeled as such until a reviewer accepts it. A system should also be able to say that it cannot establish a match. Forcing every document into a sample record can create a plausible-looking error that becomes harder to spot after export.
Product teams can use the NIST AI Risk Management Framework as a general structure for examining these risks. In this example, the specific design task is to keep uncertain extraction from becoming an unqualified project fact. Testing should include contradictory documents and missing pages, not only clean reports from one laboratory.
Distribution through technical review
An entry route would be a small group of environmental consultancies willing to evaluate a demonstration workspace. The sales discussion should center on their review packet: what belongs in it, what gets checked, and what causes rework. A product that exports into an existing reporting process may be easier to trial than one that demands a new process for every project participant.
Execution would require environmental domain expertise, secure project separation, clear permissions, and careful handling of revisions. Customer onboarding should define who can import records, who can confirm suggested matches, and who can approve an internal review. None of those roles should be inferred from a person’s ability to open a link.
DirtAI.com fits this direction because it gives soil-related information work a direct category identity. The acquisition discussion should describe the proposed product shape, the intended consulting customer, and the first three modules in practical terms. The name can open the conversation; the product must earn confidence through records that a qualified reviewer can inspect.