What this site covers, and what it does not¶
This is a subset of Tend's documentation, published deliberately. Reading a gap here as a gap in the product would be a mistake, and so would the reverse. This page says which is which.
The corpus documents the platform through feature 005¶
Every page here describes the governed lifecycle plane as it stood at the end of feature 005: the App CRD and the operator, the admission and network baselines, the two gateways, the evidence chain, lifecycle and cost enforcement.
Four later features are absent from these pages entirely — not withheld, simply not written about yet:
| Feature | What it added |
|---|---|
| 006 | A falsification spike that selected the builder engine |
| 007 | The prompt → running app loop: authoring, the governed build, and a digest-pinned deploy |
| 008 | Platform-service visibility in the estate portal |
| 009 | A cloud-hosted demo environment at feature parity with local |
| 010 | A browser interface in front of the builder, for the business user |
Writing that coverage is separate work. Until it exists, treat this site as accurate about what it describes and silent about what came after.
Some pages are published and some are not¶
Publication here is default-deny: a page appears on this site only by being named on an explicit allowlist, reviewed by a named owner, and verified line by line against the source code at a named commit before it first appears. Most of the corpus is absent because nobody has completed that verification for it — not because anything about it is sensitive.
A smaller set of pages is held back deliberately. They are operational detail about a specific deployment's gaps: bypasses in a local development path, fixtures that are deferred, the exact conditions under which a check does or does not apply. Tend's authoring rules oblige every engineer to write those disclosures down, and that obligation is not negotiable — but an operational gap register is a different artifact from a documentation site, and mixing them serves nobody.
What that does not mean. The withheld pages are not a second, truer set of claims that contradicts what is published. Where withholding a page would have stranded a caveat, the caveat moved to the published page rather than disappearing with the page that carried it. If a published page states something more strongly than the code delivers, that is a defect in the published page, and it is the kind of defect this site's verification process exists to catch.
What the verification marker on each page means¶
Each published page carries a marker naming a commit, a date, and a person. It means exactly this:
On this date, this named person read this page line by line against the repository at this commit, and found no claim the code at that commit does not implement.
It does not mean the page is complete — verification tests what the page says against the code, never the code against the page. It does not mean the page is true now: it was true at the commit named, and everything since is unmeasured drift. And it does not mean anything ran. The check is a source read. Tend's own standard for its two non-negotiable principles is that they are described as proven only when a live run is named, and a verified page saying "the gate holds" means a human read the policy, not that anyone watched an admission be refused.
Absence is not evidence¶
Two rules follow, and both are load-bearing:
- The absence of a page is not the absence of the capability. Most of the product is undocumented here.
- The absence of a caveat on a page is not evidence there is no caveat. If you need the full operational picture for an evaluation, ask for it rather than inferring it from what is published.