HomeOpen source9 projects · Apache-2.0

Open source at Sigrix

The parts of this platform that other people have to build against, we publish. A marketplace can be a product; the contract an agent is run and licensed under should not be one. So the protocol under Sigrix is drafted in the open, under a licence anyone can use, with the specification as the thing everybody pins to rather than our implementation of it, which is published too: the runner inside every bundle a buyer downloads is a package of its own, and so is the page an agent is run from in the browser. The same applies one level up and one level down: the client a seller publishes through and the launcher a buyer's client starts are source you can read before you paste a token into either, and the library that opens every image uploaded here is a package you can install and use for something that has nothing to do with us, and so is the tool that announces each update here on every channel we post to. The format a playbook is written in is published with the cases anyone can check one against. Bailey, the assistant the solutions sold here are built for, is open from its first release.

Projects
9 · Bailey, Postern, Gatehouse, sigrix-mcp, sigrix-launcher, sigrix-runtime, mullion, Herald, Muster
License
Apache-2.0
Specification
0.1 · draft
Organisation
sigrix-io
The map

How the pieces connect

One protocol between the projects: a seller publishes to Sigrix, Sigrix delivers a bundle, and the page and the runner meet over Postern's four verbs, on the buyer's own machine. Select a project to jump to it.

Swipe the map sideways to see all of it; every connection is also written out below.

  1. sigrix-mcp → sigrix.io A seller publishes a draft from their editor through the seller API, into the review queue.
  2. sigrix.io → sigrix-runtime Every bundle Sigrix delivers carries the runner, and the runner asks Sigrix whether the buyer still owns the listing before it runs anything.
  3. sigrix.io → Gatehouse Sigrix draws its run page and its previews with Gatehouse.
  4. Gatehouse → Postern Gatehouse calls a runner's four verbs over fetch, from the browser.
  5. sigrix-runtime → Postern sigrix-runtime serves the four verbs as the specification's complete implementation, the entitlement check included.
  6. sigrix-launcher → sigrix-runtime The launcher checks the purchase and downloads the seller's package with the runtime's own client code.
  7. Bailey → Gatehouse · planned From its 0.1, Bailey draws a solution's apps with Gatehouse.
  8. sigrix.io → mullion Every image uploaded to Sigrix is opened, fitted and encoded by mullion.
  9. sigrix.io → Herald Sigrix announces each update it publishes on its Hub through Herald, which counts every text the way its channel does and keeps its record of what was posted in Sigrix's own store.
  10. sigrix.io → Muster Sigrix checks every playbook uploaded to it against Muster, with a checker of its own held to Muster's case table, and serves Muster's schema at its permanent address.
  11. Gatehouse → Muster Gatehouse draws what a playbook holds, its files in order and the placeholders a buyer fills in, from its Muster playbook.json.
Projects

What we maintain

The assistant the solutions sold here are built for, the protocol everything else on the platform sits on, the page an agent is run from in the browser, the client sellers publish through, the launcher buyers start what they bought with, the runner inside every bundle, the library that handles every image you upload, the tool this platform announces each update with, and the format a playbook is written in.

github.com/sigrix-io ↗
Assistant In development Apache-2.0

Bailey

An open-source AI assistant that runs ready-made solutions on your own machine, with your own AI key.

Getting AI to do one real job reliably is still a project: someone writes the instructions, connects the tools, supplies the documents and the keys, and keeps it all working when something changes. Bailey is being built to run solutions instead: complete, versioned packages for one job, installed in one step, that ask only for the keys they need and ask before any tool changes something, on your machine and with the AI provider you choose. It is built in the open from its first release, which checks that a machine has what the assistant will need. Solutions will come from anywhere, since they are open formats, and from Sigrix, where the people who build them sell them.

Repositorysigrix-io/bailey
Packagebailey · PyPI
LicenseApache-2.0
RequiresPython 3.11+
Installuvx · pipx
uvxbaileydoctor
Specification v0.1 · draft Apache-2.0

Postern

The open execution and entitlement protocol for packaged AI agents.

You bought or downloaded an agent. It is a folder on your machine. Now what? Today the answer is different for every agent, so every client that wants to offer something nicer than a terminal has to hard-code that knowledge per agent — which means nobody does it. Postern fixes the interface, not the agent: four HTTP verbs an agent serves, and a licensing check the packaging standards leave as metadata only.

Repositorysigrix-io/postern
Specification0.1 · draft
LicenseApache-2.0
Complete impl.sigrix-runtime · Level 3
InstallDocker · pip
describerunstreamstatus
Browser client Postern v0.1 · draft Apache-2.0

Gatehouse

A browser client for Postern: the page a person runs an agent from, for any runner that serves the four verbs.

Given a runner's describe and status documents, Gatehouse draws a form for its inputs, a run button, the steps as they happen and the result with what the run used, then connects the page to the four verbs over fetch. Beside that page it draws an app's card, a run history and a usage summary from a host's own data, for a page of several apps, and what is inside a playbook from its playbook.json. It holds nothing else: six scripts and a stylesheet, with no build step, no runtime dependency and no second origin. Nothing an agent returns is ever parsed as HTML. It draws the buyer's run page, the seller's preview, the admin preview and a playbook's contents on Sigrix, and became a package of its own once Bailey needed the same page for a solution's apps.

Repositorysigrix-io/gatehouse
Package@sigrix-io/gatehouse · npm
LicenseApache-2.0
Requiresa browser · a Postern runner
Installnpm · or copy src/
postern_client.jsrun_view_model.jsrefusal_copy.jsrun_renderer.jshost_blocks.jsplaybook_contents.js
MCP server Seller API v1 Apache-2.0

sigrix-mcp

Publish prompt, persona, skill, MCP server and assistant listings to Sigrix from the AI client you already write in.

Authoring a listing and publishing one happen in different places: the writing is done in Claude Code, Claude Desktop, Cursor or VS Code, and then re-typed into a web form. This is the second half, handed back — an MCP server that takes a draft from a sentence to the review queue without a browser. It is deliberately thin: no model of its own, no copy of any rule, and no secret beyond your seller token. What submit would refuse it asks Sigrix and repeats verbatim, and nothing it can reach publishes anything — a submission is queued for moderation exactly as one made in the wizard is.

Repositorysigrix-io/sigrix-mcp
Packagesigrix-mcp · PyPI
LicenseApache-2.0
RequiresPython 3.11+ · a seller token
Installuvx · pipx
list_categorieslist_my_listingsget_listingcreate_draftupdate_draftcheck_draftsubmit_for_reviewimport_skill_mdexport_skill_md
Launcher Postern v0.1 · draft Apache-2.0

sigrix-launcher

Start an MCP server you bought on Sigrix from the client you already use.

Some listings are a seller's own software, delivered by Sigrix rather than published anywhere: a package only its buyers can download. This is what a buyer's MCP client starts for one. On every start it asks Sigrix whether your token owns the listing, downloads the seller's package and verifies it before anything is written, installs it into an environment of its own once per version, and hands your client's stdio to the seller's server. The purchase check and the download are sigrix-runtime's own client code, and neither package needs anything beyond the Python standard library.

Repositorysigrix-io/sigrix-launcher
Packagesigrix-launcher · PyPI
LicenseApache-2.0
RequiresPython 3.11+ · your Sigrix token
Installuvx · pipx
uvxsigrix-launcherrun<seller>/<listing-id>
Runner v0.1.0 Apache-2.0

sigrix-runtime

The Postern runner inside every bundle Sigrix delivers: the four verbs and the licence check, on the buyer's own machine.

Every agent a buyer downloads from Sigrix carries this package. It serves the agent's describe, run, stream and status on loopback, asks the distributor whether the buyer's token still owns the listing before it runs anything, and can serve an MCP server's tools over the same four verbs. The server needs nothing beyond the Python standard library, so it answers before anything is installed; a CrewAI crew runs through it once its extra is. It was a directory in the Sigrix repository until it became a package of its own, and the version this row reads is the one every bundle built here carries.

Repositorysigrix-io/sigrix-runtime
Packagesigrix-runtime · PyPI
LicenseApache-2.0
RequiresPython 3.11+
In use here0.1.0
Installin every bundle · pip
posternexecutionworkforceloaderconfigurationsandboxquietrunner_env
Library v0.2.2 Apache-2.0

mullion

One correct way to open an image: EXIF orientation applied, transparency resolved rather than dropped.

Every picture anyone hands this platform — an avatar, a storefront cover, a sample render — is opened, fitted, sometimes marked and re-encoded by this library. It exists because the defect it prevents is invisible: each upload path decided orientation and transparency for itself, they reached different answers, and the wrong ones stored a cutout on a black rectangle behind a 200 response and a picture that renders. It was a module in the Sigrix repository until a second codebase needed exactly it, and it has no marketplace in it: what the watermark says is ours, drawing it is not.

Repositorysigrix-io/mullion
Packagemullion · PyPI
LicenseApache-2.0
RequiresPython 3.11+
In use here0.2.2
Installpip
sourceresizewatermarkencodebackgroundpage
Tool v0.2.0 Apache-2.0

Herald

One announcement to every channel you choose: each text fitted to its platform, shown before it is sent, and posted once.

Herald posts an announcement to Bluesky, Mastodon, Discord, Slack, Telegram, a LinkedIn profile or page and X, from one command, a feed it watches, a GitHub Action, an assistant over MCP or a Python call. It counts each channel's text the way that platform does and refuses a post that is too long rather than cutting it, shows exactly what each channel will get before anything is sent, then posts that draft and keeps a ledger, so the same announcement is never posted twice. The Hub announces each update through it, with Herald's ledger kept in this platform's own store. Nothing in it is specific to Sigrix, and it needs nothing beyond the Python standard library.

Repositorysigrix-io/herald
Packageherald-post · PyPI
LicenseApache-2.0
RequiresPython 3.11+
In use here0.2.0
Installpip · uvx
announcementdraftscountingchannelspostingledgerfeedsmcpclihttp
Format v0.1 Apache-2.0

Muster

The playbook format: one playbook.json that says what each file is for, the order a person works through them, and the placeholders a buyer fills in.

A playbook is a process a business runs by hand, sold as the files a person works through: the steps, the copy to send, the checklists and the tools that work offline. Muster is the document beside them, with a JSON Schema at a permanent address and a table of cases, valid documents and invalid ones each made by one change, that every implementation runs. Its README states the rules no schema can: every file named is in the folder, every placeholder used is declared, and an HTML file loads nothing from the network. Sigrix checks every playbook uploaded to it against the format and Gatehouse draws what one holds; anyone can write a playbook, and check its playbook.json against the schema, without either.

Repositorysigrix-io/muster
Format0.1
LicenseApache-2.0
Schemaplaybook.schema.json · served here
Cases4 valid · 35 invalid
format_versionnametitleorderfilesslotsexamples_are_fictional
On PyPI and npm

Published packages

Each one is released from its own repository above, under the same licence. These are the names pip and npm resolve — worth copying rather than guessing, since a near-miss on either registry installs somebody else's code.

How we work in the open

Three commitments

01

The document is what you pin to

Sigrix runs a Postern implementation, but the specification is the definition. Where the two appear to disagree, the document wins and the disagreement is worth an issue.

02

Published before it is finished

Feedback is cheapest while changing things is still free, and that is only true if everyone knows it is still true. The specification is not tagged, and we say so on every page.

03

No dependency in either direction

A distributor is optional, the schemas work without ever being fetched, and the Sigrix profile is one any implementer may ignore. Nothing in the protocol requires our services.

Everything we publish lives in one organisation
Issues and pull requests are read there. It is the only community surface we run today.
github.com/sigrix-io Open on GitHub ↗