Teamcentric Forge
Closed betaKeep technical documents true without maintaining every fact by hand.
Write the explanation in ordinary Markdown. Mark the facts that change, then let the CLI resolve them from live systems at build time in your own environment — with provenance for every value.
Teamcentric Forge is in closed-group testing. Access is invite-only.
release-evidence.generated.md
Built 4 minutes ago · version 7
- Release v4.2.1
git.latest-release
- Commit 9f2c1ab
git.commit
- Disk used 61%
filesystem.filesystem-capacity
- API health 200 · 184 ms
http.health-check
forge build resolved every value on this machine, and recorded where each one came from.
Fig. 1 — A generated document, with the built-in block that resolved each value. Sample data.
The problem
The prose is rarely the part that goes stale
What decays are the release numbers, capacity figures, inventories and health checks copied out of systems that carried on changing afterwards.
- The deployed version in the runbook, three releases behind
- A commit hash and release tag that describe last quarter's build
- Disk and capacity figures somebody measured once, by hand
- An endpoint inventory that no longer matches the service
- A release evidence pack rebuilt from screenshots every time it is asked for
The unit of work
A document is Markdown, plus the blocks that resolve it
An executable block is a fenced code block with a stable, document-local id. It says which system to ask and what to ask for — never how to reach it, and never a secret.
release-evidence.md
---
title: Release Evidence
forge:
version: 1
profile: production
---
## Release under test
```docblock
id: latest-release
provider: git
operation: latest-release
parameters:
repository: ./service-api
render:
as: key-value
```- ID's are how blocks compose
- A later block can reference an earlier one's result, which makes it an input rather than a neighbour. Forge executes in dependency order rather than document order.
- Retrieval and presentation are separate
- The provider decides what data is retrieved; the renderer decides how it appears — as text, a scalar, a key-value list, a table, Markdown or JSON.
- The generated document is clean
- A build writes rendered content only — no block syntax, no metadata — beside a separate provenance sidecar. What a reader receives is a normal Markdown document.
Who uses it
For documents people act on, not merely read
Forge is for the teams maintaining release evidence, on-call runbooks, architecture records and environment inventories by hand today.
- Platform and infrastructure engineers
- Environment inventories, capacity figures and host details that are true on the day somebody reads them, because they are read from the host rather than remembered.
- Release managers and delivery leads
- Release evidence assembled from the repository and the service itself — tag, commit, branch and health — regenerated per release instead of re-collected by hand.
- Architects and technical leads
- Architecture and design documents whose version numbers, service inventories and dependency facts stay attached to the systems they describe.
- SRE and operations teams
- Runbooks that carry current service health, filesystem state and host information, so the first thing an on-call engineer reads is not out of date.
- Documentation owners and technical writers
- Keep authoring prose in ordinary Markdown, and stop being the person who manually reconciles every number in it before a review.
- CI and pipeline owners
- Regenerate documents on every build with a scoped, read-only service credential, and fail the pipeline when a document can no longer be generated truthfully.
Permissions
Authoring and generation are different privileges
People who create and publish documents hold tenant roles. CI retrieves published versions through a read-only service identity.
- Publisher One tenant
- Creates, edits, versions and publishes documents and Library Blocks, and retrieves them through the CLI.
- Tenant Admin One tenant
- Everything a Publisher can, plus membership, groups and service identities.
- Service identity CI and automation
- Non-human caller with least-privilege read scopes. Generating a document needs no write permission, so it cannot author or publish.
- Super Admin Platform only
- Administers the platform. Holds no tenant membership, so it reaches no document, block or CLI resource — even in a tenant it is configuring.
Revoking a membership invalidates the tokens it authorised immediately.
Capabilities
Give documentation the controls you expect from a build
Validate before publishing, generate from an immutable version, lock reusable dependencies, and retain the provenance of every result.
- Markdown stays Markdown
- Executable parts are fenced blocks, so the source is still an ordinary Markdown file. Anything the parser does not recognise — another tool's fence, a diagram — is preserved byte for byte.
- Declarative blocks, not scripts
- Retrieving the latest release tag or checking an endpoint is configuration, not code. Every operation publishes a parameter schema and a result schema, so validation, the composer's forms and the CLI cannot disagree.
- Drafts and published versions
- A document has one mutable draft and any number of immutable, sequentially numbered published versions. The server revalidates before publishing, and an invalid draft gets no version number.
- Reusable Library Blocks
- Publish versioned blocks that compose built-in operations and other blocks, then reference them from documents by semantic version range. Publishing checks the whole contract, so a block cannot be released in a state that only fails later.
- Locked, reproducible builds
- A build records each resolved version and its content digest in a lock file, and the lock is the input to the next resolution. Publishing a new block version does not silently change what a rebuild produces.
- Provenance for every value
- Each build writes a sidecar recording which source produced a block, when it was retrieved, which operation ran, and whether the value came from a live source or a cache.
- Execution stays in your environment
- Nothing in the browser or the Web API executes a block or resolves a credential. Generation happens only where you run the CLI — a laptop, a CI runner, a build server inside your network.
- Failure handling you choose
- Per block: stop the build, record a warning, leave a visible placeholder, or reuse the last recorded result within an age limit you set. A reused result is marked stale rather than passed off as fresh.
- Generation audit
- Every build of a tenant document reports success or failure with operational metadata only — version, digest, timings, error codes. Source, generated content and credential values are never in it.
Built-in blocks
What a document can ask for today
Four providers ship with the platform. Each operation publishes its parameters, its result shape and the capabilities it needs, so a document is checked against the real contract rather than a description of one.
- git
-
- commit
- branch
- latest-tag
- latest-release
- http
-
- get
- health-check
- filesystem
-
- exists
- list
- file-size
- directory-size
- file-metadata
- directory-metadata
- filesystem-capacity
- checksum
- assert-presence
- text-parse
- system
-
- os-info
- cpu-info
- memory
- runtime-info
- filesystem-capacity
Repository state for a working copy the CLI can reach
JSON or text from an endpoint, selected with a JSON path
Paths, sizes, digests and parsed text from the build host
Read-only host inspection through native OS APIs
Beyond the built-ins
A team publishes its own Library Blocks — versioned, reusable blocks that compose built-in operations and other blocks and shape the result. Documents reference them by version range, and an exact pin is always the reproducible choice.
How it works
Authored centrally, generated where the systems live
The web application manages and validates documents. The CLI is the only thing that executes them.
-
Step 01
Write the document
Author ordinary Markdown in the web Composer, and add a fenced block wherever a fact should come from a system rather than from memory.
-
Step 02
Validate and publish
The Composer validates structure, schemas, references and dependency cycles. Publishing creates an immutable, numbered version — the only thing the CLI will ever build.
-
Step 03
Build where the systems are
Run the CLI on a laptop, a runner or a build server. Credential aliases resolve from a local profile, and preflight refuses a document that would breach its allowlist or capabilities.
-
Step 04
Keep the snapshot and its record
You get generated Markdown beside a provenance sidecar and a lock file. The build reports its outcome back to the document's generation activity.
The application
What it looks like in use
The document library, with each document's path, published version and current state.
Execution boundary
A document must not become a way to run code
Anything that resolves live data is a security question first. Forge answers it by keeping execution, credentials and network access on your side of the boundary.
- Documents never contain secrets
- A document names a credential alias. The value behind it is resolved from a local profile at build time, in the environment that owns it.
- Allowlists and capabilities are checked first
- A profile carries the hosts a build may reach and the capabilities it may use. Preflight rejects a document that would breach either, before any provider runs.
- Tokens are stored as digests
- A copy of the database contains no working credential, and revoking a membership deletes the tokens it authorised by foreign key rather than by an application check.
- Generation can be switched off per document
- Taking a document offline stops every retrieval — including the owner's, an admin's and CI's — without touching the draft, its versions or authoring.
What it does not do
Forge is in closed-group testing and is built in stages. The first list is what is not implemented yet; the second is what it is deliberately not trying to become.
Not built yet
- Inline scripts and custom code inside a block — blocks are declarative today
- Providers beyond Git, HTTP, filesystem and host inspection
- Single sign-on and OIDC — authentication is Forge-owned email and password
- Publishing a generated snapshot back into Forge, or to a destination system
- Scheduled generation — a build is always started by you or your CI
- Native OS credential stores for the CLI, and formal compliance attestation
Not the job
- A CI/CD engine
- An infrastructure automation platform
- A secrets-management system
- A notebook environment
- A general remote shell manager
- A full document-processing suite
Start with one document you are tired of correcting
Forge is in closed-group testing with a small number of teams, onboarded as a guided pilot. Tell us which document goes stale fastest and which systems hold the facts in it — a runbook, a release evidence pack, an environment inventory.