A report that consumes the morning
You collect the same exports, reconcile the same fields, and rebuild the same report.
What you get
A repeatable data workflow with validation and a report format agreed with you.
Private Engineering / By inquiry
From a recurring problem
to a useful tool.
Custom automation, data tools, and prototypes, built around your environment. Tell us the task that is in the way and the result you want.
What we build / Examples
The problem sets
the shape of the work.
Tools that do not talk to each other
The useful information is split across systems and moved by hand.
What you get
An integration or local data tool with documented inputs, outputs, and failure handling.
An idea that needs a working test
You need to find out whether an architecture or technical premise is practical.
What you get
A focused prototype, tests that answer the question, and a clear read on what comes next.
An agent workflow that needs oversight
Automated work is difficult to inspect or review before it changes something.
What you get
Inspection tools, review steps, and records tailored to the workflow's permitted actions.
How an engagement runs
Agree what success
will look like.
Deliverables, acceptance checks, and handoff are agreed in writing before the build starts.
- 01
Describe the problem
Send the task that is in the way, the tools involved, the result you want, and any constraints. No confidential files yet.
- 02
Agree scope and terms
We agree the deliverable, how it will be checked, what is out of scope, data handling, timing, and price. Nothing is built before this is written down.
- 03
Build and verify
The agreed deliverable is built and checked against the agreed acceptance tests. You see the evidence, not just a report that it works.
- 04
Hand it over
You receive the source, documentation, and verification records set out in the scope.
One completed piece of work / Internal Greyforge project
oremap:
a map before the cleanup.
- The problem
- Greyforge's own machines had accumulated systemd units, timers, cron entries, wrapper scripts, and cloned repositories over months of small decisions. Cleaning up meant choosing between leaving everything alone and removing things by guesswork.
- What was delivered
- A read-only command-line tool, first released publicly in Python as service-cartographer v0.1.0 and now published as oremap, a native Rust binary. It inventories systemd units, cron jobs, executable wrappers, Git repositories, and env-file metadata into one reviewable matrix, output as Markdown, JSON, or CSV. It runs on demand: no daemon, scheduler, web server, or remote collector.
- What was verified
- Before publication the v0.1.0 release passed Ruff, pytest, the Python package build, the Twine package check, and the OpenForge readiness status. The privacy defaults redact the hostname, shorten home paths, hide env-file values, and mask common credential-looking command fragments.
- Safe by design
- It is read-only. It never stops units, edits crontabs, deletes repositories, or uploads reports, so a scan can run anywhere without risk.
- Where it came from
- Built for Greyforge's own cleanup, then released as open source.
InputA throwaway home directory with two wrapper scripts (one untouched since March), two Git repositories (one with uncommitted changes, one idle since February), and one .env file. systemd and cron collectors were switched off so the run touched nothing real.
Command, as captured with service-cartographer v0.1.0
service-cartographer scan --systemd-scope off --no-cron --repo-root ~/fixture/repos --wrapper-dir ~/fixture/bin --format markdown| Action | Kind | Name | Status | Reason |
|---|---|---|---|---|
| keep_candidate | repository | ingest-worker | status=dirty | repository has local changes |
| retire_candidate | repository | report-builder | status=clean | no recent activity for 217 days |
| retire_candidate | wrapper | old-sync | status=executable | no recent activity for 180 days |
| review | env_file | .env | status=present | needs owner decision |
| review | wrapper | ingest-worker | status=executable | needs owner decision |
The matrix separates what to keep from what to retire before anything is disabled or deleted: an idle wrapper and an idle repository become retirement candidates, a repository with local changes is kept, and anything the tool cannot decide, such as an env file, is handed back to the operator for review. The report also counted the env file's two variables without printing their names or values.
NoteA small fixture keeps the output easy to read. The 180-day inactivity rule is the default and can be tuned to your environment. The hostname is redacted by the tool's own default.
oremap v0.1.0 (released as service-cartographer) on GitHub ↗Start the conversation
What would you like
to stop doing by hand?
Send the problem, the result you want, the constraints that matter, and a reply address. A timeline and budget range help. Hold confidential files until data handling is agreed.
Email contact@greyforge.tech ↗Contact & purchase support ↗