Case study · Information management · open core

A workflow should fit the work. Not the other way around.

GIMS is an open-source database and workflow platform for work that does not fit cleanly into spreadsheets or rigid off-the-shelf software.

When the main application cannot express the real process, staff fill the gaps with side spreadsheets, folders, and remembered steps. GIMS makes that process explicit, structures the information that needs to survive each step, and gives reporting, APIs, and automation a shared foundation.

First paying clientOpen core on GitHubPython · FastAPI · React + Glide · SQL

Open the demo ↗gims-oss on GitHub ↗The refactor report →

The problem

The workflow changes, but the software does not. People become responsible for bridging the gaps and keeping records consistent.

What changed

Configurable schemas describe the records and actions. The engine generates workbenches, run logs, and artifacts from those definitions.

Why it matters

Information can be reused across the process. A changed workflow can become a configuration change instead of another application rebuild.

Architecture / gimsThe design behind the outcome

The process becomes an explicit model.

The grammar describes nouns (things you track), verbs (actions), adjectives (descriptors), adverbs (context), conjunctions (run overrides), and prepositional phrases (intent that triggers an artifact). These definitions generate the data model, workbenches, run logs, and artifacts. Laboratory, onboarding, and approval workflows can be represented as different schemas over the same engine.

I [TEST] this [SAMPLE] on [HPLC] [for_COA] → a run that produces a Certificate of Analysis

Walking the demo five chapters, driven by the gnome, on the real UI

The GIMS demo start screen: the gnome, the five grammar words Noun, Adjective, Verb, Enter data, Runlog, and the Start the walkthrough button

gims-demo.vercel.appthe start screen

Welcome: the parts-of-speech idea

The demo is a gnome-led, chaptered walkthrough that builds a small GIMS grammar end to end. In a few minutes you define a noun, describe it with an adjective, define a verb, enter a record, and operate in the runlog. It looks and behaves like GIMS, but it has no real backend, no real authentication, and stores nothing. Any login works.

Real front end, mock backend: mock/gims-mock.js overrides window.fetch before the page bundles load and answers GIMS endpoint paths from an in-memory store. The React pages are the prebuilt bundles from GIMS itself, never regenerated in the demo.

Chapter 1, Noun: a Sample with two clocks

A noun is a kind of record. The gnome picks the Demo Lab project and the Sample noun, switches the schema from View to Edit, and adds three fields: received_at and due_at, both datetime, and a hold_clock field that the next chapter turns into a live timer.

This is the noun configure workbench with the tour peeked away, so the screen underneath is the one a user gets.

The noun configure workbench: a fields table for the Sample noun listing sample_id, received_at, due_at, and hold_clock, with New Field and Save Changes buttons

gims-demo.vercel.app/pages/noun_configure.htmlchapter 1 of 5

The adjective editor: hold_clock registered as a Duration adjective with start field received_at and end field due_at

gims-demo.vercel.app/pages/adjective_editor.htmlchapter 2 of 5

Chapter 2, Adjective: hold_clock becomes a Duration

An adjective describes a noun. In the adjective editor, hold_clock is registered as a Duration, anchored between received_at and due_at, in the mode that shows both elapsed and remaining time. Adjectives in GIMS include tags, references, lists, and these live Duration tickers.

Chapters 3 and 4, Verb and Enter data

A verb is an action you run on a noun. Chapter 3 defines an Intake verb, in a group called Lab Runs, that acts on Sample. Chapter 4 enters a real Sample record for it to operate on: the noun workbench renders a form from the schema, and the gnome fills in an id and the received and due times.

The noun workbench: a manual form for the Sample noun with sample_id SPC-100, received_at and due_at filled, and a hold_clock field, plus a bulk upload panel

gims-demo.vercel.app/pages/noun_workbench.htmlchapter 4 of 5 · enter data

The runlog workbench: an Intake run open in the Data Entry grid with three Sample rows, a hold_clock column reading 3h 0m in · 1d 1h left, one row OVERDUE, and a Clock verified badge

gims-demo.vercel.app/pages/runlog_workbench.htmlchapter 5 of 5 · the run log

Chapter 5, Runlog: the payoff

The runlog is where you run verbs and work the data. The Intake run opens in the Data Entry grid and the hold_clock column ticks live: time since received, time until due. Past-due rows flag OVERDUE.

The badge in the corner reads Clock verified: the clock is NTP-verified, the same trusted time that stamps the audit trail in the regulated product.

The same runlog with the gnome's tour bubble: 5 · The live clock, pointing at the grid

gims-demo.vercel.app/pages/runlog_workbench.html · with the gnomethe tour engine is GIMS’s own, vendored

Why a demo, and why this one

The real, 21 CFR Part 11-defensible GIMS, with keyed integrity chaining, server-of-record custody, validated time, and electronic signatures, is a separate, private system. None of that backend logic lives in the demo repository. The demo exists to show the workflow and the UI, not for regulated use, and it says so in a yellow bar on every screen.

Under the hood a layered FastAPI backend, a React + Glide front end

A full architectural refactor of a 100K+ line application.

I consolidated duplicated backend logic, integrated SQL for the backend and React for the frontend, strengthened controls for audit readiness, and improved the test suite so it reflected the application’s real operating processes.

The refactor was one branch, refactor/foundation: 152 commits across 533 files in four days, every step proven behaviour-neutral before it was committed. What made that safe: routes are decorator-defined and the guard baselines are keyed by path and name, not filename, so a move plus an import rewrite is provably wiring-neutral.

Read the full refactor report →

api/        HTTP/JSON routers (the API boundary) + api/app.py ASGI entrypoint
core/       the engine — words (nouns/verbs/adjectives/...), handlers, lineage, audit,
            orchestration (nodes/modules/registry), storage
nodes/      orchestration "nodes" (page nodes, infra nodes) wired into modules
modules/    module definitions that compose nodes into pages
frontend/   React sources (built into static/lib by build.mjs)
static/     built JS/CSS assets, icons, the guided-tour engine, skins
projects/   example projects (LIMS-System, DurationDemo, RunlogTest)
tools/      utilities
tests/      pytest suite

The dependency direction is strict: core/ never imports from api/, nodes/, or modules/. Everything is defined in JSON schemas per project; Python parsers and phrase-handlers automate calculations and artifact generation.

gims-oss, the open core what is in it, what is deliberately left out, how to run it

The repository on GitHub is the open-core edition of GIMS: the complete schema/grammar engine and every workbench, editor, dashboard, guided tour, and skin, as a fully runnable, single-user GIMS.

Three things are intentionally not in this build. They make up the proprietary layer that turns GIMS into a regulated-industry product, and the Compliance Relay demo shows them in action. In this build every request is treated as a single fully-authorized local user, workflow gates complete without a sign-off, and no audit trail is written. Run it locally to explore the engine; do not deploy it as a shared service.

How to run it

git clone https://github.com/BMA-Corgea/gims-oss
cd gims-oss
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
python -m uvicorn api.app:app --host 127.0.0.1 --port 8100

Then open http://127.0.0.1:8100/. You land on the launcher, no login required. Pick the LIMS-System demo project to explore configured nouns and verbs, run the runlog workbench, and try the guided tours. ./start.sh does the same with venv bootstrapping.

In this build

Define nouns, verbs, adjectives, and adverbs, and run the workbenches end to end
The React runlog grid, the archive workbench, and data dumps
Custom Python parsers and prepositional-phrase artifact generation
Skins (the modular theme system) and the guided product tours
The pytest suite the auth and compliance tests are not part of this build

Deliberately left out

Login / authentication multi-user accounts, JWT/cookie sessions
Roles / permissions per-project RBAC, feature-tag scopes, admin console
Compliance 21 CFR Part 11 HMAC audit chain, e-signatures, gate sign-off, sealed exports → the Compliance Relay

Photo: Yuri Shkoda, Pexels · decoration: vials in a chromatograph, the [HPLC] in the grammar line

Status, honestly

GIMS has its first paying client: one client paid to start the project. The open core is on GitHub. That is the stage it is at: a working system with a first paid validation, not a mature product at scale. Where it goes next is on How I work.

Put the engineering in context

Recognize a problem in your own workflow?

Show me one task your team does by hand. In 20 minutes, I’ll tell you if it’s worth automating and what it would cost.

Book a free 20-minute check Explore the other projects →