Source & deployment policy — bRRAIn Docs

How bRRAIn source code is protected and how all deployable artifacts reach you.

Source & deployment policy

This page is the canonical statement of how bRRAIn protects its source and how every artifact you receive — binaries, charts, container images, SDKs, marketplace extensions, content packs — gets to you.

Source code is private

The bRRAIn source repository at Qosil/bRRAIn is and will always remain private. This isn't a temporary state — it's the policy.

What this means:

  • We do not publish the platform source.
  • We do not accept public pull requests against the platform repository.
  • Customer contracts, support relationships, and partner agreements do not grant source access except under narrow, contracted source-escrow arrangements for qualifying Enterprise and Sovereign-Cloud customers.
  • Open-source dependencies remain licensed by their respective licenses; we comply with their attribution and redistribution requirements.

What this protects:

  • The integrity of the platform — no fork divergence, no impersonation of bRRAIn binaries.
  • The investment we and our customers have made in bRRAIn's differentiation.
  • Customers' security posture — proprietary defenses that would be diluted by public source.

All deployable artifacts ship from our servers

Every binary, container image, Helm chart, marketplace extension, SDK package, and content pack you receive ships from infrastructure we operate. We never ship deployables from public package registries.

Specifically:

  • bRRAIn binaries (brain pod, web, console, marketplace, admin, exchange, auth, registry) ship from deploy.brrain.io and equivalent customer-bound URLs.
  • Container images for self-hosted deployments ship from our customer-bound registry.
  • Helm charts ship from our customer-bound chart repository.
  • Marketplace extension tarballs ship from our deployment-asset storage, fetched by your pod's supervisor.
  • SDK packages ship from our SDK distribution (not from public PyPI / npm / Maven Central / Go module proxies). You can configure your package manager to point at our customer-bound registries.
  • Content packs (Exchange purchases) ship via our deployment-asset storage.

The deployment path is end-to-end customer-bound:

  • Authenticated downloads keyed to your customer license.
  • Signed artifacts (we sign with our internal CA; verification keys ship with your bundle).
  • TLS in transit.
  • Tamper-evident manifests.

Why we don't use public registries

Public package registries (GitHub Container Registry public images, public Docker Hub, public NPM, public PyPI) are convenient but they introduce risks:

  • Supply-chain attacks. Compromise of a public registry can introduce malicious artifacts into customer environments. By keeping bRRAIn distribution off public registries, an attacker can't slip a poisoned brrain image into a customer's pull path.
  • Typosquatting. Public registries are full of typosquatted packages. We eliminate this attack vector by never being on a public registry in the first place.
  • Availability dependence. Public registries have outages. Our customer-bound distribution doesn't share that fate.
  • Deprecation risk. Public registries can change policy, delete artifacts, or change discoverability. Customer-bound distribution is contractually stable.

How to verify what you have

Every artifact carries:

  • A manifest file listing the artifact, its size, and its SHA-256 checksum.
  • A signature over the manifest using our internal CA.
  • Our public signing key (delivered with your initial bundle; rotation-versioned).

Before any artifact is run:

# Verify the manifest signature
gpg --verify bundle.manifest.sig bundle.manifest

# Verify the artifact's checksum matches the manifest
sha256sum --check bundle.manifest

The Docker Compose, Kubernetes, and Operator install flows do this automatically. For ad-hoc artifact handling, do it yourself.

What you can share publicly

You're welcome to share:

  • That you use bRRAIn.
  • Case studies, blog posts, conference talks about your bRRAIn deployment.
  • bRRAIn-issued certifications.
  • Verification chips you've issued from your bRRAInUserID.

You should not share:

  • The contents of any bRRAIn binary, image, chart, or SDK package outside your organization.
  • Internal documentation, runbooks, or other materials we provide that are marked confidential.
  • Configuration secrets that grant access to our distribution endpoints.

What we share publicly

Everything user-facing — these docs, the website, the marketplace catalog descriptions, the partner program terms, the certification curriculum syllabi, the bR2bR open standard, the API surface documented here.

The implementation behind the user-facing surface stays private.

Open standards we publish

While the platform source is private, we publish open standards that the broader ecosystem can build against:

  • bR2bR — the bRRAIn-to-bRRAIn open standard for cross-organization memory queries with cryptographic provenance.
  • bRRAIn Platform SDK contract — the interface marketplace extensions and SDK callers use to talk to a brain pod.
  • Documentation conventions — the structure of this docs site.

Open standards are versioned, freely usable, and contributed to as appropriate community standards.

Compliance considerations

  • SOC 2 — our distribution chain is audited as part of our SOC 2 scope.
  • ISO 27001 — distribution security controls are part of our ISMS.
  • FedRAMP / CMMC — for in-scope customers, our distribution path is part of the system boundary documented and audited.
  • Software Bill of Materials (SBOM) — we provide SBOMs to customers under NDA.

Reporting suspected compromise

If you ever suspect:

  • An artifact you received has been tampered with.
  • A registry URL has been changed without prior notice.
  • A signing key is being misused.

Contact security@brrain.io immediately. Our standard response includes invalidating any potentially-compromised distribution channel, issuing fresh artifacts, and full incident disclosure to affected customers.

Where to next