What you can verify, not just read.
paimos is FOSS, AGPL-3.0, and maintained by one person. None of those make it more trustworthy on their own — what matters is whether the claims on this site can be checked against artefacts the project produces. This page lists those artefacts and how to verify them.
Where evidence doesn't exist yet, this page says so. Where the trust model has limits — and a solo-maintainer FOSS project always has limits — this page names them rather than hiding them.
Every release is signed, accompanied by an SBOM, and traceable to a specific git commit.
Each git tag vX.Y.Z publishes a Docker image at ghcr.io/markus-barta/paimos:X.Y.Z. The image manifest digest is signed keylessly via cosign + GitHub's OIDC token. Two CycloneDX SBOMs (Go modules + npm packages) are attached as cosign attestations against the same digest.
Verify a release on your own machine before pulling it into production:
cosign verify ghcr.io/markus-barta/paimos:<x.y.z> \ --certificate-identity-regexp '^https://github.com/markus-barta/paimos/.+' \ --certificate-oidc-issuer 'https://token.actions.githubusercontent.com'
No long-lived signing key is stored anywhere. The workflow's OIDC token is the only thing that can produce a signature for a given digest. If a fork ever produced a `paimos` image with the same tag, the signature would not verify against the canonical identity-regexp above.
Pull the SBOM attestation directly off the registry:
cosign download attestation \ --predicate-type 'https://cyclonedx.org/bom' \ ghcr.io/markus-barta/paimos:<x.y.z> \ | jq -r '.payload | @base64d | fromjson | .predicate'
Live links to the artefacts that back every public claim.
The links below resolve directly into the canonical source — the GitHub repo, the GitHub Releases page, or the registry. They are not derivative summaries; they are the documents themselves.
- repository github.com/markus-barta/paimos
- releases + signed images + SBOMs github.com/markus-barta/paimos/releases
- claim → evidence matrix docs/claim-matrix.md
- 2.0 audit + decision report docs/2.0_AUDIT.md
- incident response runbook docs/INCIDENT_RESPONSE.md
- disclosure policy SECURITY.md
- security advisories (when published) github.com/markus-barta/paimos/security/advisories
- changelog docs/CHANGELOG.md
- brand framework + phasing plan docs/brand/BRAND.md
Found a security issue? Here's the path.
Email securitypaimos.com with subject [PAIMOS security] <brief description>. Acknowledgement within 72 hours; if not, re-send via a different channel.
Full disclosure policy in SECURITY.md. Coordinated-disclosure model: triage in 7 days, fix-target 30 days for high severity, public advisory ~7 days after the patched release lands so operators have a window to update.
Internal handling — severity ladder, runbooks per incident class, post-incident review template — is documented at docs/INCIDENT_RESPONSE.md. Reporters don't need to read it; it's there for transparency.
Severity ladder: Sev 0 data exposure / RCE / auth bypass — TTA < 4h, fix < 24h. Sev 1 priv-esc / data integrity — TTA < 24h, fix < 7d. Sev 2 limited-scope vuln — TTA < 7d, fix < 30d. Sev 3 process gap — TTA < 30d, fix in next minor release.
Only the most recent release gets fixes — and that's a deliberate choice.
Per SECURITY.md § Supported versions: only the most recent release branch is supported with security fixes. paimos is solo-maintained; multiple long-lived release branches exceed sustainable solo-maintainer capacity. Operators on older releases must upgrade to receive fixes.
Update cadence is event-driven, not calendar-driven. A Sev 0/1 fix lands in a patch release as soon as it's tested. A new minor release lands when there's a coherent feature surface to ship. There is no LTS programme and there will not be one until paimos has more than one full-time maintainer.
paimos is currently in Phase 2 (Platform), live since v2.0.0 (2026-04-26). Phase 1 (FOSS) remains active alongside; transitions in the brand model are additive. Brand colour and trademark filings are Phase 2 deliverables, not Phase 2 gates, and stay deferred until earned. See about for the four readings of the name and the brand framework.
What you shouldn't take on faith.
The trust posture is built on what the project can actually evidence. Some bars haven't been cleared yet, and pretending otherwise would defeat the point of this page.
- Solo-maintained. Bus-factor of one. The runbooks and audit docs exist precisely so a future maintainer can pick this up; they don't change the bus-factor today.
- Pre-1.0 → 2.0 in one cycle. The 2.0 audit (2.0_AUDIT.md) covers backend / DB / frontend / tests / release / branches / product architecture / planning hierarchy. Trust posture-related governance items (formal threat-model doc, public hardening checklist, recurring independent technical review programme) are in the open backlog and named there.
- Single primary deployment. The reference deployment is
pm.barta.cm(the maintainer's own instance). Real adoption proof-pack is a roadmap item. - Local-AI integrations on the roadmap, not shipped. The site says so on the homepage (03 / specs · Local AI roadmap) and the claim matrix says so. PAI-122 is the rollback ticket that brought the public copy into line.
- No third-party security review yet. The April 2026 internal audit produced PAI-109 (defects) and PAI-124 / PAI-136 (process). External review is on the roadmap as a recurring programme; nothing has been independently certified.