{"slug": "syzygy-package-and-version-integration-knowledge-as-reusable-cli-plugins", "title": "Syzygy – Package and version integration knowledge as reusable CLI plugins", "summary": "Syzygy, a new open-source CLI tool from the company of the same name, packages integration knowledge into versioned, reusable plugins that run locally on Node.js 20, with AI-authored tests and a requirements-traceability matrix, aiming to eliminate the bottleneck of knowledge residing in individual engineers. The tool, free for commercial use, runs entirely on the user's machine or CI runner, ensuring payloads, credentials, and reports never leave the network, making it suitable for banks, hospitals, and government departments.", "body_md": "### Runs on your machine\n\n`npm install -g syzs-cli`\n\n— anywhere Node.js 20 runs. No server, no account, no telemetry. Payloads, credentials and reports never leave your network.\n\nAlign every artefact — from requirements to results\n\nYour team's integration knowledge lives in a Postman collection, a stale Confluence page, and one senior engineer's head. SYZYGY turns it into a **versioned plugin your whole organisation installs** — with AI-authored tests, deterministic execution, and a requirements-traceability matrix that's always current.\n\nTest at any level — component, integration, E2E — from the same artefacts. Switch environments with one flag. Nothing duplicated, nothing drifting.\n\nRuns entirely on your own machine or CI runner: your payloads, credentials, and results never leave your network. **Free to use, including commercially.**\n\n01 The problem\n\nMost organisations carry their integration knowledge in five places at once: a Postman collection on one engineer's laptop, a Confluence page two years out of date, a custom test framework someone built and left behind, a folder of CI scripts no one owns, and the head of the senior engineer who is about to take a different job. None of those things are wrong. None of them are *aligned*.\n\nEvery team automates testing the same way: they build a framework first. Then the people who knew how the systems integrated leave, and the knowledge leaves with them. What follows is always the same pattern — a custom runner no one fully understands, a folder of \"helpers\" that grew organically, credentials stored in places they shouldn't be, a Confluence page two years out of date, and one engineer everyone defers to about which endpoint to call in what order. That engineer becomes a bottleneck. When that engineer leaves, so does the knowledge.\n\nThe hard part of testing modern software has never been writing assertions. The hard part is **where your integration knowledge lives**: the endpoints, the request shapes, the order of operations, the negative-path expectations, the rules a manager calls \"how we actually work.\" Frameworks let you write tests. They don't help you keep the knowledge that makes those tests worth writing.\n\nSYZYGY treats integration knowledge as the artefact. It packages that knowledge into one durable, versioned form — a plugin — and gives every developer, every test phase, and every environment the same source of truth. You version it (a git tag). You install it (`syz install`\n\n). You reuse it across every level of testing your team does, against every environment, by every developer. When the engineer leaves, the plugin stays.\n\n`PLUGIN-GUIDE.yaml`\n\n/ `DOMAIN.yaml`\n\n, in plain language, before a plugin exists.`.syz/`\n\n. Convention over config.`syz install`\n\n.`syz init`\n\nlays down the framework. The AI assistant they already use is configured automatically.02 What it is\n\nOne binary. Nothing else to operate.\n\nSYZYGY runs the whole testing lifecycle from one place — and it starts with knowledge, not code. The people who know what a system must do capture it in plain domain language as a concrete, schema-validated spec, *before a single plugin exists*. `syz generate`\n\nturns an API spec into a runnable plugin. Scenarios wire those plugins into tests. The runtime executes them deterministically and writes a report anyone can read. `syz rtm`\n\nties every result back to the requirement it proves. The lifecycle below renders that path, stage by stage.\n\nUnderneath it is a single Node.js CLI (`syz`\n\n, package `syzs-cli`\n\n) that runs declarative YAML scenarios against versioned plugins that encode how your systems integrate. Scenarios, plugins, test data, and environments all live in your git repo as plain text — no server, no database, no central registry, and **nothing about your work leaves your network**: no cloud, no account, no telemetry. That is what makes SYZYGY usable inside a bank, a hospital, or a government department without a vendor security review.\n\n**Plain YAML, and it works without AI.** Execution is fully deterministic; only the authoring conveniences — drafting specs, payloads, and semantic checks — call a model, and only when you configure a provider. AI is the recommended fast path, never a requirement.\n\nRuns over HTTP today; the executor registry is built so Kafka, SQL, SFTP, gRPC and more drop in without changing how you author a test — [see the full roadmap](/depth#roadmap).\n\nThe SYZYGY lifecycle, from requirement capture to requirements traceability\n\nDay one, `.syz/dossier/`\n\nalready ships the knowledge layer that supports the first three stages — so capturing requirements and authoring scenarios in plain language works from the very first command.\n\n`npm install -g syzs-cli`\n\n— anywhere Node.js 20 runs. No server, no account, no telemetry. Payloads, credentials and reports never leave your network.\n\nShare integration knowledge the way you share libraries. Versioned by tag, installed with `syz install`\n\n, pinned in `dependency.json`\n\n.\n\nDeclarative, diffable, reviewable in code review. Same scenario across every test phase — switch the environment file.\n\nDeterministic runtime; bring any OpenAI-compatible provider for the parts that genuinely benefit from reasoning.\n\n03 The artefacts\n\nFive real captures from genuine runs — not mockups. They run in lifecycle order: a requirement written in plain language, and four artefacts later, that same requirement proven by a test. Click any one to see it full size.\n\n04 Who it's for\n\nIt starts with the people who own *what \"correct\" means* — and reaches every team that has to prove it. Four shapes of team; if yours rhymes with any, this is the tool.\n\n**Where it bites hardest.** SYZYGY earns its keep fastest in **regulated, REST-heavy organisations** — financial services, healthcare, insurance, government — where two costs are already being paid in full: proving to an auditor which test covers which requirement, and losing a decade of integration knowledge every time a senior engineer resigns. Teams outside those industries get the same mechanics; teams inside them have a budget line for the pain.\n\n01 / Product owner · BA · SME\n\nDocument each integration's behaviour and the cross-service journeys as a concrete, schema-validated spec — `PLUGIN-GUIDE.yaml`\n\nand `DOMAIN.yaml`\n\n— in plain domain language, drafted with any AI assistant out of the box, before a single plugin exists. Every requirement gets a stable ID; `covers:`\n\nlinks the tests to it; `syz rtm`\n\nproves the coverage. The knowledge that used to live in one person's head becomes a reviewed, versioned, traceable artefact.\n\n02 / Platform team\n\nYou own a payments API (or an orders API, or an auth API). Twelve other teams call it. You spend a non-trivial fraction of every sprint answering \"what's the right payload for endpoint X\" and \"we got a 400, what does that mean\". Today, every consumer team has their own ad-hoc test setup. With SYZYGY, you publish a `payments`\n\nplugin — one git repo, one `syz install`\n\nline for every consumer. Endpoints, payloads, validators, negative-test expectations, common workflows — all versioned, all in one place, all reused. New consumers onboard in an afternoon. Breaking changes propagate via a version bump.\n\n03 / Integration team\n\nYou have component tests against mocks, integration tests against a shared staging instance, end-to-end tests against a production-like environment, and UAT against a stakeholder-facing slice. Today, you maintain four different test suites. With SYZYGY, you maintain *one* set of scenarios and *four* environment files. Same plugins, same scenarios, different `--env`\n\nflag. When the API changes, you update the plugin in one place, bump the version, and re-pin in every consumer's `dependency.json`\n\n.\n\n04 / QA lead · test manager in a regulated environment\n\nYou need exit codes that mean something, JUnit XML that GitHub Actions and Jenkins read natively, deterministic verdicts, and audit artefacts you can hand to compliance. With SYZYGY, every run produces an immutable ledger, a phase-by-phase debug log, a JUnit XML (`--reporter junit`\n\n), and a requirements-traceability matrix (`syz rtm`\n\n, with `--strict`\n\nas a CI gate that fails the build on any uncovered requirement). Every artefact is a plain file in git, reviewable in a pull request — so the evidence pack for a release is a commit range, not a screenshot folder assembled the week before the audit. Live progress panels are opt-in (`--live-stats`\n\n) for your local executions. Sensitive fields are masked everywhere, including the report. The exit code is a per-verdict signal CI can branch on — `0`\n\nall passed, `1`\n\na check failed, `2`\n\nbad input or setup, `3`\n\nan upstream system faulted, `4`\n\nno verdict delivered, `130`\n\ninterrupted.\n\n05 Straight answers\n\nCost, licence, data, maturity, and how this differs from the tool you already use. No prose to wade through.\n\nThe API-testing landscape is crowded and mostly free, and every tool in it is good at *calling an API and asserting on the response*:\n\nEach is strong at its job. But they all start from the *call*, and at best codify the behaviour they just observed — there's no requirement to trace back to. SYZYGY isn't another entry in that list: it treats **integration knowledge** as the artefact. Requirements are first-class and schema-validated (`PLUGIN-GUIDE.yaml`\n\n/ `DOMAIN.yaml`\n\n); tests link to them with `covers:`\n\n, and `syz rtm`\n\nderives the traceability matrix. Plugins are versioned and installed across your org like libraries, execution is deterministic, and nothing syncs to a vendor cloud. Keep the client you like for ad-hoc calls — SYZYGY is the durable, provable layer underneath.\n\nA model can draft test scripts — but two problems remain. **Generation drifts:** ask twice and you get two different shapes, and you still own and maintain whatever it produced. `syz generate`\n\nis **deterministic** — no model in the path, reproducible on every run — and it emits a complete, enterprise-grade framework (runtime, immutable ledger, HTML + JUnit reporting, and the traceability matrix), so the *framework is off your plate*, not something a model reinvents per prompt.\n\n**And the knowledge takes the big seat.** Raw model-written scripts bury what the system is supposed to do *inside the script*, where it drifts and can't be traced. SYZYGY inverts that — testing starts from knowledge captured as a durable, schema-validated artefact (`PLUGIN-GUIDE.yaml`\n\n/ `DOMAIN.yaml`\n\n), and the tests derive from it and trace back to it with `covers:`\n\n. The model still helps you author — but against a versioned contract, with deterministic execution and a matrix proving coverage, not a pile of scripts no one owns.\n\nYes — and keep it. Jira, Azure DevOps Boards, Confluence, Linear, monday.com, or a formal tool like Jama Connect or IBM DOORS are built to capture and triage work, and SYZYGY doesn't replace planning. Two problems, though. **Mapping those tickets to the tests that prove them is manual**, and deriving a requirements-traceability matrix from them is ongoing, hand-maintained effort. **And those boards are organised around teams, not systems** — scrum, squad, project. When a project closes or the org restructures, that work is archived; finding one system's requirements in an ocean of tickets, then migrating years of work, is heavy lifting few people ever finish. You end up with tests and no record of *why* each one exists.\n\nSYZYGY captures requirements as **schema-validated artefacts tied to the system** — `PLUGIN-GUIDE.yaml`\n\nper integration, `DOMAIN.yaml`\n\nfor cross-service journeys — each carrying a **stable id** (`REQ-…`\n\n), versioned in git and linked to tests with `covers:`\n\nfrom day one. `syz rtm`\n\nderives the matrix on demand, never by hand.\n\n**And nothing is orphaned from where it started.** Record the originating ticket — its id or URL — in the requirement's `references`\n\nfield, and tag that ticket with the SYZYGY `REQ-…`\n\nid in your tracker: the two now point at each other, so anyone can trace a test back through its requirement to the original ask, and forward again. Unlike the ticket, that cross-reference lives in git history — it survives the requirement changing, the project closing, or the board being archived. Keep your planning tool for triage; SYZYGY is where the *durable, system-aligned, test-linked* requirement record lives.\n\nBDD's promise is one shared, business-readable spec. In practice, the pressure to reuse and optimise step definitions bends the `Given`\n\n/ `When`\n\n/ `Then`\n\nto fit the technical flow — open your `.feature`\n\nfiles and ask honestly how much a non-technical domain owner can still read. The business language and the automation are welded into the same file, and the automation usually wins.\n\nSYZYGY splits them cleanly. **Requirements are the business-language layer** — `PLUGIN-GUIDE.yaml`\n\nrecords each behaviour as plain-English `given`\n\n/ `when`\n\n/ `then`\n\n, owned by the people who know the domain. **Tests are the technical layer** — scenarios in YAML, written however they need to be — and they simply **link back** to the requirements they exercise with `covers:`\n\n. `syz rtm`\n\nthen shows precisely which test covers which requirement. Domain owners write requirements in plain language; engineers write tests without contorting them into a business-readable DSL. Neither side compromises to satisfy the other.\n\nNothing. The CLI is free to install and use — no paid tier, no seat count, no usage limit, and no trial clock. That includes use inside a commercial, for-profit company: a bank automating its integration testing pays nothing.\n\nThe one boundary is **monetising the software itself**. You may not resell it, host it for third parties, offer it as a service, or use it to build a competing product. Use it as intended, free, forever; don't repackage it as your own. Anything outside that, email [enquiry ]. syz.sh\n\nDeliberately. SYZYGY is **free to use, but proprietary** — the source isn't public and it isn't open to community forks. That's a stewardship choice, not a commercial one. The method underneath it — knowledge as the artefact, every requirement aligned to a result — is easy to dilute, and we've watched respected test frameworks lose their way once they fragmented into a dozen incompatible flavours, each drifting from the intent that made the tool worth having.\n\nWe'd rather nurture SYZYGY carefully, shaped by how real teams use it and what they tell us, than optimise for how many variants exist. **Even the finest tool rusts into a liability when it's wielded without care** — and the real world offers no shortage of examples. Free to use, yes; free to fragment, no. Ideas, needs, and requests genuinely steer it — that's what [support ] is for. syz.sh\n\nNowhere. There is no SYZYGY cloud, no account, and no telemetry — nothing about you, your systems, or your tests is collected. Payloads, credentials, responses and reports stay on the machine that ran them. The CLI's only outbound calls are: your systems under test, your git remote on `syz install`\n\n, your own AI provider if you configure one, and a single npm-registry version check that sends no data about you, is dormant in CI, and is disabled with `SYZ_NO_UPDATE_CHECK=1`\n\n. [Full detail on the depth page](/depth#how).\n\nIt's **pre-1.0, early access, and honestly labelled.** The execution model, ledger, reporting, and traceability are shipped and stable — everything shown on this site works today. What's not there yet is protocol breadth: HTTP is the only executor, with Kafka, SQL, SFTP and the rest on the [roadmap](/depth#roadmap) and prioritised by what teams actually ask for. Sensible move today is a single-team pilot, not an org-wide rollout.\n\nNo, and that's a design goal rather than a slogan. `syz init`\n\nconfigures the AI assistant your team already uses with the full framework contract, so requirements capture and scenario authoring happen in plain language — see the AI-assistant capability on the [depth page](/depth#capabilities), and the plain-language playbook in the dossier. And the runtime doesn't require AI at all — it's plain YAML, executed deterministically; AI only assists authoring when you configure a provider. What you *do* need is someone comfortable reading YAML when a test fails: the artefacts are designed to be legible, not opaque.\n\nIt's not a load-testing tool, not a mocking framework, not consumer-driven contract testing, not UI/browser automation today, not a hosted service, and not an API client — keep your GUI for ad-hoc calls.\n\nThough today it runs **API and contract testing over HTTP** — that framework is complete and shipping — with Kafka, message queues, UI/browser automation and more on the [roadmap](/depth#roadmap). So you *can* use it as a testing tool, and you're welcome to. But it isn't designed to *replace* the testing tool you already have.\n\nThe whole design idea is bigger than testing: preserve what your organisation knows and prove your systems behave as they're expected to. Testing capability of SYZYGY is to prove that your knowledge is implemented as intended. In short — **align your every artefact, from Requirements to Results.**\n\nAligned\n\nOne command. Node.js 20+. No infrastructure to stand up.", "url": "https://wpnews.pro/news/syzygy-package-and-version-integration-knowledge-as-reusable-cli-plugins", "canonical_source": "https://syz.sh", "published_at": "2026-08-02 09:50:06+00:00", "updated_at": "2026-08-02 10:22:59.277637+00:00", "lang": "en", "topics": ["developer-tools", "ai-tools", "artificial-intelligence"], "entities": ["Syzygy", "Node.js", "Postman", "Confluence"], "alternates": {"html": "https://wpnews.pro/news/syzygy-package-and-version-integration-knowledge-as-reusable-cli-plugins", "markdown": "https://wpnews.pro/news/syzygy-package-and-version-integration-knowledge-as-reusable-cli-plugins.md", "text": "https://wpnews.pro/news/syzygy-package-and-version-integration-knowledge-as-reusable-cli-plugins.txt", "jsonld": "https://wpnews.pro/news/syzygy-package-and-version-integration-knowledge-as-reusable-cli-plugins.jsonld"}}