Teamcentric Forge: Documents That Gather Their Own Facts

Teamcentric Forge is a platform for executable technical documentation: people write the meaning and context, and connected systems supply the facts when the document is generated.

It is late on a Thursday and an engineer has to produce a release handover before the change window opens. The explanatory part is the easy part — they know what changed, which behaviour the on-call team should watch, and which config flag is new. The tedious part is everything else. Which commit is actually deployed? Are the health endpoints returning what they should right now? Which artifacts came out of this build, and are they the ones referenced in the ticket? So the engineer opens four browser tabs and a terminal, copies values into the document by hand, and hopes nothing shifts between now and the handover call.

Two days later somebody asks whether the document still reflects reality. Nobody can answer with confidence, because the document is a photograph with no timestamp and no record of where the picture was taken.

The problem is not writing. It is transcription.

Technical documents rarely go stale because the prose was wrong. They go stale because the facts wrapped inside the prose were copied out of systems that kept moving. Release references, service health results, artifact details, file contents — all of it drifts while the surrounding explanation remains perfectly useful.

The work this creates is familiar and quietly expensive:

• Repeated checking. Before every review, somebody re-verifies the same handful of values by hand.
• Copy-and-paste updates. Fixing a stale document means visiting each source system again and pasting the new value in the right place.
• Inconsistent reports. Two engineers documenting the same release pull different fields, in different formats, from different places.
• Uncertainty. A reader cannot tell whether a value was true when it was written, true last week, or never checked at all.

Teams usually respond by writing less documentation, or by accepting that some of it is decorative. Neither is a good outcome when the document is meant to serve as evidence for a review, or as the first thing an on-call engineer reads at 3 a.m.

What “executable documentation” means here

Forge source documents are written in Markdown, the way any technical document would be. What makes them executable is that selected sections behave as reusable instructions for gathering and presenting facts, rather than as static text. Instead of pasting the current commit reference into a sentence, the author writes the sentence and marks the place where that reference should be retrieved.

When the document is generated, those sections are carried out. The narrative stays exactly as the author wrote it; the factual parts are filled in from the systems that hold the answers. Alongside the readable output, Forge produces provenance information so a reader can see where each generated fact came from.

The division of labour is the whole idea: people write the meaning and context, and connected systems supply the changing facts.

flowchart LR
    A["Human-written context"] --> C["Generate document"]
    B["Facts from source systems"] --> C
    C --> D["Readable snapshot"]
    C --> E["Provenance record"]

The diagram above is the shape of every Forge document. Two inputs meet at generation time — the explanation a person wrote, and the facts retrieved from source systems — and two things come out: a document a human can read, and a record of where its facts came from. The snapshot is what you circulate; the provenance is what you consult when someone asks how a value got there.

The documented integrations today are deliberately unglamorous categories: HTTP endpoints, Git repositories, and local files. Between them they cover much of the release-handover problem — service checks, source-control references, and information about files produced by a build.

It is worth being clear about what Forge is not. It is not an AI writing tool. It does not draft your explanation, summarise your release, or generate prose on your behalf. The writing is yours.

From authoring to generation

Forge separates the work of composing a document from the act of running it.

flowchart LR
    subgraph Authoring["Authoring and publishing"]
        A["Compose document"] --> B["Publish version"]
        R["Reusable building blocks"] --> A
    end
    subgraph Execution["User or team-controlled environment"]
        C["Generate published document"] --> D["Document snapshot and provenance"]
        S["Accessible source systems"] --> C
    end
    B --> C

Reading left to right: authoring and publishing happen in the browser, and generation happens elsewhere — on an engineer’s machine or in an automation environment the team controls. The single arrow between the two halves is a published version. That is the only thing generation consumes.

In sequence:

1. An author writes a document in Markdown and includes sections that retrieve facts rather than restating them.
2. Teams organise documents and reusable building blocks in shared libraries, so the same fact-gathering section can be reused across many documents instead of being reinvented.
3. Authors deliberately publish a version when it is ready to be generated. Drafts stay drafts.
4. A user generates the document with the command-line tool, either locally or in a team-controlled automation environment.
5. Forge retrieves the relevant facts and produces a readable snapshot together with provenance information.

Generated output stays in the environment where generation ran, by default — including when the source document came from the shared library. Authoring is collaborative; execution is local to whoever ran it.

One property matters more than any other: a snapshot reflects the moment it was generated. It is not a live dashboard and does not keep itself current. If you want a current picture, you generate again.

Why the design choices earn their keep

Design choice	What it gives you
Human narrative alongside generated facts	The context, caveats and intent survive; only the volatile values are machine-supplied
Facts retrieved at generation time	Far less manual transcription, and less opportunity to paste the wrong value
Reusable, versioned building blocks	Recurring documentation gets standardised instead of re-derived per author
Deliberate publishing	A clear line between work in progress and source approved for generation
Versioning of the document definition	The definition is stable; changing source systems can still yield different factual results
Provenance records	Traceability — a reader can see where a value came from, which is not the same as a guarantee that the upstream source was correct
Generation in the user’s environment	Documents can draw on resources reachable from that environment
Explicit failure handling	Depending on configuration, generation can stop outright or visibly flag missing or stale information rather than silently producing a confident-looking blank

That last row deserves emphasis. The failure mode to avoid is not an error message; it is a document that looks complete and is not.

Where this fits

• Developers preparing release handovers — explanatory notes, a source-control reference, endpoint health results, and artifact information in one generated document rather than five tabs.
• Platform and DevOps teams documenting operational state — runbooks and environment overviews whose factual sections are gathered rather than remembered.
• Technical writers maintaining explanations wrapped around changing technical facts — the prose stays owned by the writer, and the values that keep invalidating it stop being their problem.
• Teams collecting traceable technical evidence for review — a snapshot plus provenance, generated at a known moment, in an environment the team controls.

These are applications the approach suits, not claims about existing customers or certifications.

The honest caveats

Forge moves the effort of gathering facts; it does not abolish the conditions that make facts gatherable. Source systems have to be available and reachable from wherever generation runs, access permissions have to permit the retrieval, and the output is bounded by the quality of the sources: a document faithfully reporting a misconfigured health endpoint is faithful, not correct. Provenance helps a reader trace a value to its origin — it does not vouch for that origin.

Nor is a snapshot a reproducibility guarantee. Versioning stabilises what the document asks for; if the systems answering have changed, the answers change with them, so two generations of the same version can legitimately differ.

Back to Thursday afternoon

The engineer still has to write the handover, and they should — nobody else knows why this release matters, what to watch, or which flag is new. What they no longer have to do is act as a courier between five systems and a Markdown file, then defend the freshness of numbers they typed by hand.

They write the explanation. Forge gathers the facts for that particular snapshot, records where each one came from, and stamps it with the moment it was true.