Work

A ticket goes in. A decision comes back.

Support teams already have a helpdesk. What they often lack is a clear call on the ticket in front of them: decline it, let it through, or hold it for a person.

judged.systems sits in front of that helpdesk. One ticket goes in through REST, a webhook, or MCP. The model returns evidence. Your thresholds make the call.

Three outcomes, and only those

Each ticket lands on one of three decisions:

• reject — clear enough that your rule declines it
• review — inside the range you marked for a person
• accept — clear enough that your rule lets it through

Uncertain evidence, and a failed call, stay in review. A floor, a range, or a middle band is what holds a ticket for someone.

Built to stay thin

The helpdesk stays the system of record. judged.systems is the layer that turns a ticket into a decision you can act on later, without replacing the queue you already run.

It is in beta. Try it on judged.systems.

The missing layer in shared living

Most shared homes run on a loose mix of group chats, spreadsheets, bank transfers, and memory. Prostir brings the parts a household shares into one focused place.

It is designed around the home rather than around a single tenant. Residents can understand what needs attention, make decisions, and move on with their day.

One home, one system

Prostir connects the routines that usually become fragmented:

• shared finances, balances, and upcoming dues
• bookings for bathrooms, laundry, and common spaces
• household routines and notification preferences
• guest access and temporary codes
• utilities, energy usage, and connected-home controls

The goal is not to turn a home into a dashboard. It is to make coordination quiet enough that the people living there can focus on living.

Product direction

The first version focuses on visibility and everyday coordination: clear state, few decisions per screen, and actions that make sense without onboarding.

Prostir is currently in beta. Request access on prostir.nl.

Seeing the stream, not the noise

Most telemetry setups either drown you in raw events or hide everything behind a heavy platform. Flux sits in between: a compact pipeline that keeps the firehose fast, then turns it into summaries you can actually look at.

It started as a way to watch live systems without standing up a full observability stack. Three small programs do the work — one emits metrics, one aggregates them, and one shows the result in a terminal.

Built for attention

The interesting part is not the protocols. It is the feeling of watching something move without the UI getting in the way.

Flux keeps the ingest path lean so high-frequency data stays cheap to move. The dashboard side stays simple on purpose: readable snapshots, quick filtering, and a terminal interface that reconnects when things restart.

What it is for

Flux is useful when you want live visibility on a machine you control — demos, local systems, or small services where a managed observability product would be more ceremony than signal.

The repository is open source and meant to be read as a complete, working system rather than a framework.

A durable record of what happened

Every serious product eventually needs an answer to a simple question: what changed, when, and for whom? Most teams either bolt something together or buy a closed audit system they cannot inspect.

Unitrail is an open-source alternative. It takes events in quickly, keeps the heavy work off the request path, and stores a tenant-scoped history you can query, replay, and deliver as signed webhooks.

Designed around trust

Audit trails only matter if people believe them. Unitrail is built so ingestion stays fast, tenants stay isolated, and the path from event to durable record is explicit enough to reason about.

The goal is not another dashboard full of infrastructure. It is a clear system for capturing important product actions and keeping that history usable later — for support, compliance, debugging, or customer-facing activity feeds.

Open by default

Unitrail is MIT licensed and meant to be understood end to end. You can run it locally, read the contracts, and see how events move from the SDK into storage and outbound delivery.

It exists for teams who want audit infrastructure they can own, inspect, and shape around their product — not rent as a black box.

Banking for the table

Game nights are full of half-counted cash, disputed balances, and someone asking whether the transfer already happened. Boredbank replaces that with a shared digital bank built for play.

Players keep balances, send money, and follow the state of the table without slowing the game down. Familiar banking patterns make it feel obvious; the context keeps it light.

Serious enough to trust, light enough to enjoy

The interesting constraint is balance. Transfers need to feel quick and clear without pretending play money is real finance.

That means explicit amounts, obvious recipients, immediate feedback, and a history that settles the “did that go through?” question before anyone leaves the table.

Around the board

Boredbank is designed for phones beside a physical game: fast onboarding for everyone there, one shared source of truth, and controls that stay readable when attention is mostly on the board.

Open Boredbank and start a table.

Discovery that begins with your data

Most recommendation demos assume someone else already cleaned the catalog and wrote the ranking logic. SKNQ starts earlier: upload a dataset, answer a few preference questions, and get a shortlist that feels personal to that moment.

It turns a spreadsheet of options into a guided discovery flow — questions, ranked matches, and room to say what landed or missed.

Learning from taste, not just similarity

The first pass mixes preference questions with semantic search so results feel relevant quickly. Feedback then becomes a signal for the next ranking, so the system can adapt without rebuilding everything from scratch.

The point is not to impress with model names. It is to make choosing from a large set feel lighter: ask what matters, show a few strong options, and improve from what people actually pick.

Built to be tried

SKNQ is open source and intended as a complete, readable product: upload, questionnaire, results, and feedback in one loop. Useful for anyone exploring recommendation UX, or turning a messy catalog into something people can navigate.