Skip to content

About this documentation

This page explains how the Endeavor Engineering knowledge base is written, reviewed, and published — so you can judge how much to trust what you read here.

Markdown in Git is the source of record

Every page on this site is generated from a Markdown file held in a version-controlled repository. Nothing is authored in the published site or edited in place. That has a few consequences worth stating plainly:

  • Every page has a change history. Each revision is a commit with an author, a timestamp, and a reason.
  • The "last updated" date on each page is real. It comes from the git history of that specific file — the date its content last changed, not the date the site was last rebuilt.
  • Documentation lives next to what it documents. A connector's documentation sits in the connector's repository, so it moves when the code moves and is reviewed alongside it.

Publishing is automated

Pages are published by an automated release process rather than by hand. A person decides what to write and when it is ready; the machinery decides nothing but where it goes. Publishing therefore leaves a record: which commit produced which page, and when.

This is deliberate. Documentation that is copied around by hand drifts, and drift is invisible until it misleads someone.

Authored with AI assistance, reviewed by engineers

EEI uses AI assistance as part of how this documentation gets written — drafting, restructuring, cross-checking against the code and architecture records it describes.

We think it is worth being straightforward about that, and equally straightforward about the limit: AI assistance does not replace review. An engineer is accountable for every page here. The material is checked against the systems it describes, and where documentation and reality disagree, the documentation is wrong and gets fixed.

The combination is why this knowledge base exists at all. Small engineering organizations usually choose between shipping product and documenting it. Working this way, we do not have to.

What this documentation is not

  • It is not a specification of unreleased capability. Where something is planned rather than available, pages say so.
  • It is not a substitute for the agreements in your contract. Support commitments, versions, and scope are defined there.

Getting more out of this site

This page covers how the documentation is produced. If you want the practical companion — how the site is organized, how to search it well, and what the icons and dates on a page mean — see Using this documentation.

Found a problem?

Errors in documentation are usually the cheapest problem we can fix, and the most useful thing you can tell us about. Corrections, gaps, and "this was confusing" are all welcome.

Report an issue with a page →

Every submission reaches a tracked queue and is read by a person.