Berryman Data Systems, LLC

Software that has to be right, and has to keep working.

Custom applications, database engineering, and systems integration — built on open technology, and yours to host, change, and keep.

Discipline
Application and data engineering
Method
AI-assisted, verification-first
Registration
Georgia LLC · NAICS 541511

What we build

  • Custom application development

    Web applications and internal tools, built end to end — interface, API, and database.

    Web applications · Internal tools · APIs · Interfaces

  • Database engineering

    Schema design, query performance, and migrations that finish with the same data they started with.

    Schema design · Query performance · Migrations · Data integrity

  • Systems integration

    Interfaces between systems that were never designed to exchange data: REST and XML services, scheduled transfers, and field-level mapping between schemas.

    REST · XML · Scheduled transfer · Field mapping

  • Legacy systems

    Software that still runs the organization and is not going to be replaced this year. Keeping it in service, getting data in and out of it, and giving it interfaces to current systems — including running the original application under emulation when the platform it was written for no longer exists. Where replacement is the goal, it happens in stages, with parallel operation and reconciliation against the system of record while the work continues.

    Emulation · Data extraction · Interfacing · Staged cutover · Reconciliation

  • Reporting and automation

    Scheduled data pipelines, generated documents, and operational dashboards.

    Scheduled pipelines · Document generation · Dashboards

  • Cryptographic engineering

    Systems whose security properties have to be demonstrable rather than asserted: signed and verifiable exchange, client-side encryption, and key handling. Including migration to post-quantum signature schemes, which federal guidance has now put on a schedule.

    ML-DSA (FIPS 204) · AES-GCM · SHAKE-256 · Cross-language test vectors

  • Language-model systems

    Classification, extraction, and retrieval built on language models, with the evaluation harness and decision trail that make the output reviewable rather than merely impressive.

    Hosted and local models · Evaluation harnesses · Structured extraction

AI-assisted, verification-first

Current AI tooling produces a great deal of correct code very quickly. It also produces plausible code that is subtly wrong, and it does that just as quickly. The gap between those two matters more, not less, when the system has an audit or a statutory deadline attached to it.

The firm uses these tools daily, and they genuinely compress a schedule. What makes that safe is not using them tentatively — it is that what they produce has to clear the same bar as everything else.

One definition, generated outward
Schemas, types, and error codes are declared once and generated into every language that consumes them, so a change cannot land in one client and quietly miss another.
Checks that do not trust the author
Shared test vectors that each implementation has to reproduce exactly. Two components that agree because they were written the same way have demonstrated nothing; agreement against a fixed expected result is evidence.
Runs that can be repeated
Where behaviour is not deterministic, it is exercised from staged fixtures at known starting states, so a result can be re-run and compared rather than judged by eye.
A recorded reason
Automated decisions record what they did and why, with a reference back to the input that prompted it. When someone asks why the system reached a conclusion, the answer is in the data rather than reconstructed after the fact.

None of this is new, and none of it is really about AI. These are the practices that make any system inspectable by someone who did not write it — which is precisely what makes the newer tooling usable on work where being wrong is expensive.

Open technology, and the result is yours

Given the choice, the firm builds on open-source foundations. That is a practical preference rather than an ideological one, and it comes down to what happens to your system over the years after it is delivered.

Nothing can be withdrawn
Products get discontinued, relicensed, and acquired. An open component cannot be taken away from you — the version you are running keeps working, on terms that cannot be revised later.
Cost does not follow success
No per-seat, per-core, or per-record licensing, so adding users or seeing the system succeed does not increase what you pay to keep it running.
It can be inspected
Every layer is open to reading. For work that gets audited, that is the difference between showing how something is determined and pointing at a closed component.
You can hire from anywhere
Widely used tools mean a large pool of people who can maintain it, rather than a short list of certified partners.
Leaving stays possible
You get the source and the data model, hosted wherever you choose. Continuing with the firm should be a decision you make on the merits each time, not one the architecture already made for you.

None of this is a condition of working together. Plenty of organizations run on commercial platforms for good reasons, and have licences, staff, and policies already built around them. Where that is the case, the work is written to fit what you have — the recommendation is offered once, and then it is your call.

Built to be maintained

The firm's principal has spent more than twenty-five years building and maintaining production systems. A long run of that has been for public agencies, alongside microcontroller and embedded work, distributed infrastructure, cryptographic protocol design, and applied machine learning.

That range is the point rather than a list of services. Most engagements are ordinary application and data work, and the breadth is what makes unfamiliar territory a normal part of the job instead of a risk to be priced around.

Delivery is the small part. The systems we build tend to stay in service for years, so the real work is the migrations, schema changes, and regulatory updates that arrive afterward.

We document the data model, write for whoever inherits the code, and keep the system operable by people who did not build it. Clients work directly with the engineer doing the work.

Where the firm goes deepest

Some work rewards years spent in one subject. The firm's is regulated data — systems carrying federal schemas and statutory deadlines, where the reporting is the reason the system exists and it changes when the rules change. Drinking water is the deepest of those, and has its own page.

Drinking water, SDWA and EPA reporting

Firm details

Entity
Berryman Data Systems, LLC
Form
Limited liability company
Jurisdiction
Georgia
NAICS
541511 — Custom Computer Programming Services
Principal
Randall Smith, sole member
Mail
5665 Atlanta Hwy 9, Ste 102B, PMB 267
Alpharetta, GA 30004

Start a conversation