governed execution for third-party tools
Prototype
Install a capability, not an integration.
Syntagma lets a product offer someone else's tools without rebuilding a project around each one. A publisher declares a tool in a versioned manifest — what it exposes, which widget renders it, which policy gates it, how it is paid for — and an organisation installs that version. The tool then appears as an embedded widget or as a plain API call, while identity, policy, payment and audit stay with the platform instead of being written again inside every integration. The platform is called Syntagma; its code, its published packages and its protocols keep the working name xapps. Four and a half months separate the first commit from the last: 1,618 commits, a gateway with 519 documented API paths, three operator consoles, its own protocols for composition, payment orchestration and monetisation, and fourteen packages published on npm. Then it stopped. Nothing is deployed and nobody is using it — Syntagma is built and parked.
I designed and built it: the manifest and policy-gate contracts, the gateway and its background workers, the three protocol layers, the Node and PHP SDKs, the three operator consoles, the documentation, and the identity. I also set the bar for done — the full suite run and accounted for on every change, each failure chased to a real cause or a known flake before the work counted as finished — and chose to park the platform rather than launch it.
Project images
What we are building
A capability, declared and installed
A publisher packages tools, widgets, policy gates and endpoints into one versioned manifest; a version is an immutable snapshot; an installation is that version enabled for one organisation. The manifest is the contract: what is not declared and validated when the package is imported does not happen at runtime. Ten lines of it are enough for a working tool.
Policy gates decide before anything runs
A gate is evaluated at seven blocking moments — before an installation is created, before a widget loads, before a session opens, before a conversation thread opens, before a tool runs, before a link is revoked, before an uninstall — in a declared order, failing closed. A blocked call returns one canonical answer that names what would unblock it, so a payment, a consent or a step-up can be completed and the call retried. The gates are themselves installable packages: the platform checks that a gate satisfies the required contract, not who wrote it.
Four ways in, chosen by ownership
An embedded catalogue, a hosted widget, API only, or execution on the publisher's own infrastructure. They coexist, and the choice follows who wants to own what rather than anyone's technology preference. The recommended first path is deliberately the smallest: the integrator keeps its own shell, branding and login and builds a launcher plus one bootstrap endpoint, while the gateway calls, the payment and policy routes and the credential handling stay on the platform side.
The record of the run
A request is checked against the tool's declared input schema, stored with its payload encrypted under a rotating key, dispatched to the executor over a signed call, and kept as an append-only timeline with artefacts and a retrievable result. For high-assurance actions the person signs the action itself, with a passkey or a device key, and the publisher is expected to verify that signature for itself rather than take the gateway's word for it.
How it works
The organisation is the authority boundary
Users, policy and what may enter the catalogue are scoped to one organisation. An organisation can always add constraints; a publisher can never remove the ones an organisation set. An organisation's own private API is never handed to a third-party vendor — a tool reaches it only through a scope-checked proxy, so the vendor never holds those keys. Identities are not merged across organisations by email address, and the server-to-server key is deliberately unusable from a browser.
What it refuses to do
The browser is never an authority: a payment page may trust a session identifier and nothing else, not an amount, not a currency, not a return address taken from a query string, and evidence is never signed in page code. Providers adapt transport, not meaning: an adapter has to normalise its outcome into the platform's own vocabulary, and an unrecognised provider error fails closed. A read-only widget will not quietly do work on someone's behalf; it shows an empty state and waits to be asked.
An honest ledger of what is real
The project keeps its own table of what works today, what is partial and what is only specified, and this brief follows it. The composition layer runs, but the orchestration kernel its specifications describe does not: manifests, not the kernel, are still the runtime authority. The governance overlay is a design, not an implementation. The Romanian e-invoicing path builds, validates and submits invoices through its own tax-authority client, with the full status and message lifecycle, but it has never been validated against a real production tax-authority account. Adapters exist for three payment providers and none of them has taken anyone's money. The system is verified by its own test suite, not yet by a live run end to end.