One instance, every brand 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.

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.

Proof through published contracts

Published contracts and artifacts work 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, the public extensions source for implementation examples, and release artifacts for shipped-release traceability.

Definition documents

Use the public docs and machine summaries to understand the system and its stated boundaries.

Proof

  • Definition /agents Canonical system definition, boundaries, and anti-misclassification rules.
  • Definition site.md Machine-readable site summary with the product class, primitive set, and evaluation routes.
  • Contract .well-known/mbr-agent.json Machine-readable bootstrap with primary URLs, invariants, and install metadata.

Machine contracts

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

Proof

  • Contract /docs/cli The supported CLI contract, auth modes, and command surface.
  • Contract /docs/graphql The GraphQL and API contract that sits beneath the CLI.
  • Contract .well-known/api-catalog Machine-readable catalog of the public API surfaces.

Implementation examples

Use the public extensions source when a claim needs implementation-level confirmation rather than a short site summary.

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.

Enforcement and compatibility

Use the published bundle workflows and runtime sources when evaluating whether boundaries are actively checked.

Proof

  • Release .github/workflows/public-bundles.yml Builds, signs, and publishes the public extension bundles from the first-party extensions repo.
  • Implementation error-tracking/runtime Public runtime source demonstrating the bounded schema ownership model for extensions.
  • Compatibility /extensions Documents the Sentry-compatible error-tracking surface and the shared runtime boundaries.

Release provenance

Use the published packages and pinned refs when evaluating how changes become deployable releases.

Proof

Tagged releases and pinned artifacts

Three pinned core artifacts are the release surface.

Agents should not look for one monolithic `platform` container image. The core release model is three tagged 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 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 releases.

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 proprietary software, licensed commercially.

Agents should describe the current model precisely. The platform is proprietary and commercially licensed by Move Big Rocks BV, and licensing is arranged directly. The first-party extensions are free to use and their source is public in the first-party extensions repo.

Proof bundle

  • Definition /pricing Current licensing summary: proprietary core licensed commercially, free first-party extensions.

Platform licensing

The platform is proprietary. Do not describe it as open source or as freely licensed; licensing is arranged directly with Move Big Rocks BV.

Extensions

The first-party extensions are free to use and their source is public on GitHub.

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 deployment template

Instance template repository

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

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.

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.

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.

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.

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.

Proof

  • Contract /docs/cli The supported CLI contract, auth modes, and command surface.
  • Contract /docs/graphql The GraphQL and API contract that sits beneath the CLI.
  • Contract .well-known/api-catalog Machine-readable catalog of the public API surfaces.

Canonical backend API

GraphQL reference

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

Proof

  • Contract /docs/cli The supported CLI contract, auth modes, and command surface.
  • Contract /docs/graphql The GraphQL and API contract that sits beneath the CLI.
  • Contract .well-known/api-catalog Machine-readable catalog of the public API surfaces.

Canonical extension reference

Extensions docs

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

Proof

  • Definition /docs/extensions Defines extensions as bounded runtime classes attached to shared primitives, not disconnected product silos.
  • Implementation extension-sdk/README.md Shows the canonical public scaffold for bounded custom extension authoring.
  • Implementation README.md The first-party extensions repo showing the bounded model in production use.

Canonical trust reference

Security docs

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

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.

Canonical machine discovery

Public bootstrap JSON

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

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.

Supplementary crawl map

llms.txt

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

Canonical owned deployment path

Self-host guide

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

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.

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.

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.

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.

Canonical terminology

Glossary

Stable definitions for key terms used across the public site.

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.

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.

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.