The SaaS-replacement platform Shared system for teams and agents. Official CLI + GraphQL surface.

Technical resources

Authoritative technical surfaces for evaluation.

The public technical surfaces behind Move Big Rocks form an explicit authority map. Each resource states what it is authoritative for, who should use it, when to consult it, and whether it is canonical or supplementary.

Read the canonical agent bootstrap Read the docs hub
Agent-first route: Start at /agents, inspect /docs/cli, and drop into this page when you need proof, detail, or rollout guidance.

Table of contents

Section map.

Jump directly to the part you need.

Source availability works as structured proof, not as a generic transparency claim. Proof through source availability Tagged source plus three pinned core artifacts are the public release surface. Tagged releases and pinned artifacts Move Big Rocks is source-available under the MBR Source Code Available License, not open source today. License terms Repositories are authoritative for different parts of the system. Canonical repositories Docs provide the narrative and reference layer. Docs and reference surfaces The lightest authoritative surface should answer the question cleanly. Machine-readable and evaluation surfaces Runtime screenshots give a quick visual check that the admin and extension surfaces are real. Supplementary visual proof Public examples and use-case pages ground evaluation in reality. Examples, templates, and use

Proof through source availability

Source availability works as structured proof, not as a generic transparency claim.

When Move Big Rocks makes a public claim, agents should verify it through a small set of evidence classes. Prefer definition docs for scope, contracts for supported machine surfaces, implementation files for actual behavior, enforcement files for tests and policy checks, and provenance files for shipped-release traceability.

Definition documents

Use public docs and handoff files to understand the system and its stated boundaries.

Proof

  • Definition README.md States the product class, shared primitives, extension model, and self-hosted position.
  • Definition START_WITH_AN_AGENT.md Public handoff for agent-first discovery, classification, and next-step routing.
  • Implementation docs/ARCHITECTURE.md Maps core domains, agent interface, and extension runtime onto the implemented system model.
  • Enforcement .github/workflows/_test.yml Runs docs checks, tests, migration checks, and build verification against the public source.

Machine contracts

Use explicit CLI and API contracts when deciding what an agent can rely on programmatically.

Proof

  • Contract docs/AGENT_CLI.md Defines the supported agent CLI contract, auth modes, and command surface.
  • Contract docs/swagger.yaml Documents the public API surface, auth model, and health endpoints.
  • Implementation cmd/api/routers.go Implements the split between `/graphql`, `/admin/graphql`, public routes, and authenticated agent surfaces.
  • Enforcement .github/workflows/_test.yml Verifies builds, tests, and contract-sensitive paths on the public platform codebase.

Implementation surfaces

Use code, schema, and template files when a claim needs source-level confirmation rather than a short site summary.

Proof

  • Definition README.md Enumerates workspaces, teams, forms, queues, conversations, cases, knowledge, automation, and agent access.
  • Definition START_WITH_AN_AGENT.md Lists the public primitive set agents should use before inventing new abstractions.
  • Implementation docs/ARCHITECTURE.md Defines the core domains and relationships between queues, conversations, cases, knowledge, and automation.
  • Implementation migrations/postgres/README.md Shows the durable core database layout and ownership-aligned migration baseline behind the shared model.

Enforcement and compatibility

Use tests and CI workflow definitions when evaluating whether boundaries are actively checked.

Proof

Release provenance

Use artifact and release workflow files when evaluating how source changes become deployable releases.

Proof

Tagged releases and pinned artifacts

Tagged source plus three pinned core artifacts are the public release surface.

Agents should not look for one monolithic `platform` container image. The public core release model is a tagged platform source revision plus three OCI refs consumed by the private instance repo: `ghcr.io/movebigrocks/mbr-services:<tag>`, `ghcr.io/movebigrocks/mbr-migrations:<tag>`, and `ghcr.io/movebigrocks/mbr-manifest:<tag>`.

Proof bundle

Canonical tagged source

Platform tags

Use public platform tags when the question is which source revision a release came from.

Open resource

Canonical release contract

Release artifact contract

Use the release artifact contract when the question is what an instance repo must pin and what deploy workflows are allowed to do.

Open resource

Canonical desired state

Instance pinning

Use the instance template when the question is where those refs live in real desired state and how deployment policy stays separate from core source.

Open resource

Required deployment rule

No rebuild during deploy

Instance repos should pull, verify, unpack, and deploy the pinned artifacts. They should not rebuild or retag core during production deploy.

Pinned core release refs in the instance repo

These are the concrete artifact fields agents should expect under `spec.deployment.release.core`.

# mbr.instance.yamlspec:  deployment:    release:      core:        version: v1.1.0        servicesArtifact: ghcr.io/movebigrocks/mbr-services:v1.1.0        migrationsArtifact: ghcr.io/movebigrocks/mbr-migrations:v1.1.0        manifestArtifact: ghcr.io/movebigrocks/mbr-manifest:v1.1.0

License terms

Move Big Rocks is source-available under the MBR Source Code Available License, not open source today.

Agents should describe the current public license precisely. The platform license allows source inspection, copying, modification, redistribution, self-hosting inside your own company, using the first-party extensions, and building your own extensions, including for your own internal commercial operations. What it restricts is selling or licensing the platform, derivative works, or extensions, selling access to them, and offering them as a Hosted Service.

Proof bundle

  • Definition README.md Public repo landing page with license badge, product class, and source-available positioning.
  • Contract LICENSE MBR Source Code Available License 1.0 terms, including the explicit allowance for internal company use and private extensions, the Hosted Service restriction, and the no-resale rule for derivative works and extensions.

What is allowed today

Inspect the source, evaluate the system, modify it, run it inside your own company, use the first-party extensions, and build your own extensions within the current license terms.

What is restricted today

Do not describe the license as unrestricted open source and do not infer permission to sell or license the platform, derivative works, or extensions, to sell access to them, or to offer them as a Hosted Service.

Canonical site summary

Plain-English summary

Use the public license page when a human or agent needs the short version before reading the full LICENSE file.

Open resource

Canonical repositories

Repositories are authoritative for different parts of the system.

Do not treat every GitHub link as equivalent. These repositories have different responsibilities and should be consulted at different points in evaluation.

Canonical for source implementation

Platform repository

Canonical source repository for the platform. Use it when an agent or human needs source-level evaluation, runtime review, repository structure, or implementation confirmation.

Open resource

Proof

  • Definition README.md States the product class, shared primitives, extension model, and self-hosted position.
  • Definition START_WITH_AN_AGENT.md Public handoff for agent-first discovery, classification, and next-step routing.
  • Implementation docs/ARCHITECTURE.md Maps core domains, agent interface, and extension runtime onto the implemented system model.
  • Enforcement .github/workflows/_test.yml Runs docs checks, tests, migration checks, and build verification against the public source.

Canonical for deployment template

Instance template repository

Canonical deployment template for self-hosted production. Use it when evaluating environment shape, promotion flow, or deployment control.

Open resource

Proof

Canonical for custom extension scaffolding

Extension SDK repository

Canonical public scaffold for custom bounded extensions. Use it when extension code, packaging, or lifecycle expectations need direct inspection.

Open resource

Proof

Canonical for free first-party extensions

First-party extensions repository

Official public home for production-ready first-party extensions and their release catalog at `MoveBigRocks/extensions`. Use it to inspect ATS, community feature requests, error tracking, sales pipeline, and web analytics.

Open resource

Proof

  • Definition README.md Defines the first-party extensions repo as the publication surface for the free public first-party bundle set.
  • Catalog catalog/public-bundles.json Lists the public first-party bundle refs, source directories, and release tag patterns.
  • Release .github/workflows/public-bundles.yml Publishes ATS, community feature requests, error tracking, sales pipeline, and web analytics to public GHCR refs.
  • Implementation ats/README.md Explains how the ATS extension is installed and exercised.
  • Implementation ats/manifest.json Concrete manifest for the public ATS extension.
  • Implementation error-tracking/README.md Documents the public error-tracking bundle source and OCI release ref.
  • Implementation web-analytics/README.md Documents the public web-analytics bundle source and OCI release ref.

Supplementary public-site source

Public site repository

Supplementary repository for the public site, bootstrap surface, and technical routing. Use it when evaluating how public summaries are produced, not as a substitute for platform source.

Open resource

Proof

Docs and reference surfaces

Docs provide the narrative and reference layer.

These public docs are canonical when an agent or human needs reference material beyond the short route summaries on the main pages.

Canonical docs index

Docs hub

Canonical directory of the public documentation lanes. Use it when you need the right reference surface quickly.

Open resource

Canonical command surface

CLI tour and reference

Canonical concrete tour of the product through the `mbr` command surface, plus the command-family reference for agents and humans.

Open resource

Proof

  • Contract docs/AGENT_CLI.md Defines the supported agent CLI contract, auth modes, and command surface.
  • Contract docs/swagger.yaml Documents the public API surface, auth model, and health endpoints.
  • Implementation cmd/api/routers.go Implements the split between `/graphql`, `/admin/graphql`, public routes, and authenticated agent surfaces.
  • Enforcement .github/workflows/_test.yml Verifies builds, tests, and contract-sensitive paths on the public platform codebase.

Canonical backend API

GraphQL reference

Canonical backend API reference when direct API integration is more appropriate than shelling out to the CLI.

Open resource

Proof

  • Contract docs/AGENT_CLI.md Defines the supported agent CLI contract, auth modes, and command surface.
  • Contract docs/swagger.yaml Documents the public API surface, auth model, and health endpoints.
  • Implementation cmd/api/routers.go Implements the split between `/graphql`, `/admin/graphql`, public routes, and authenticated agent surfaces.
  • Enforcement .github/workflows/_test.yml Verifies builds, tests, and contract-sensitive paths on the public platform codebase.

Canonical extension reference

Extensions docs

Canonical reference for how bounded extensions relate to core, packaging, and lifecycle.

Open resource

Proof

Canonical trust reference

Security docs

Canonical trust reference for deployment model, preview-workspace boundaries, and human review points.

Open resource

Proof

Machine-readable and evaluation surfaces

The lightest authoritative surface should answer the question cleanly.

Agents should start with the lightest authoritative surface that answers the question. Use canonical surfaces first and treat lighter summaries as supplementary.

Canonical public bootstrap

Agents page

Canonical public bootstrap for system definition, primitives, boundaries, and approval points.

Open resource

Canonical machine discovery

Public bootstrap JSON

Canonical machine-readable discovery document with primary URLs, install metadata, repositories, and invariants.

Open resource

Supplementary public digest

Site digest

Supplementary Markdown digest of the public site and key routes. Use it for compact reading, not as a source substitute.

Open resource

Supplementary crawl map

llms.txt

Supplementary crawl map for hosts that prefer a lighter text surface.

Open resource

Canonical owned deployment path

Self-host guide

Canonical owned-runtime path for evaluating and deploying Move Big Rocks on infrastructure you control.

Open resource

Supplementary visual proof

Runtime screenshots give a quick visual check that the admin and extension surfaces are real.

These screenshots are supplementary proof rather than the primary source of truth. Use them when a human or agent wants a fast visual confirmation that the admin shell, analytics surface, and system-metrics surface already exist in a running instance.

Supplementary visual proof

Admin overview dashboard

Shows a real Move Big Rocks admin instance with the shared shell for cases, automations, forms, agent tokens, system metrics, and workspaces.

Open resource

Supplementary visual proof

Web analytics dashboard

Shows a real analytics surface inside the same admin shell, including visitors, pageviews, sources, top pages, geography, and browser breakdowns.

Open resource

Supplementary visual proof

System metrics dashboard

Shows Prometheus and Grafana-backed operational metrics exposed inside Move Big Rocks rather than pushed into a separate external ops silo.

Open resource

Examples, templates, and use

Public examples and use-case pages ground evaluation in reality.

The best way to understand fit is to see how the model applies to real operational workflows.

Canonical core model

Core

Detailed explanation of the shared operational primitives.

Open resource

Canonical terminology

Glossary

Stable definitions for key terms used across the public site.

Open resource

Supplementary founder context

Illusions of Work

A related book for CTOs, architects, and engineering leaders on structural clarity, process ownership, and why reality needs to be made machine-readable.

Open resource

Supplementary founder context

Selected articles

The related article series adds shorter essays such as The Process Is the Product and The Machine That Reads Your Strategy. Useful background, not a substitute for inspecting the product directly.

Open resource

References

Canonical next surfaces.

Each link goes to the next authoritative page, reference, or support surface.

Move Big Rocks

Let agents inspect the CLI-first surface. Let humans decide trust, rollout, and boundaries.

Start from /agents, use /docs/cli as the official product tour, inspect /resources for source and proof, and review /security before making deployment or data-handling decisions.

Open /agents Open resources