Coverage ledger

This ledger records scope limits and unresolved decisions. A recorded omission is still a coverage limit; it does not establish that the missing explanation is unnecessary.

It does not track per-document state. Every document carries its own status, /docs lists the collection live, and checkdocs fails on anything unfinished, so a table of statuses here would be the same information written twice and wrong first.

Screen coverage

Help claims cover the operational, reporting, reference and configuration screens. Shared guides cover related screens without duplicating their common behaviour:

• Product configuration
• Reference entities
• Ledger listings
• Users and database inspection

The deliberate exceptions are homepage, the landing page, and docs/index and docs/view, which are the documentation navigation and reader themselves. They do not need a second Help page. Run checkdocs to compare current controllers with the claims rather than relying on a stored count.

Commercial definitions, answered by the data owner

The code shows what happens; these say what the business means by it. Each is written into the document that needed it, and recorded here so the source of the answer is not lost.

The downstream tools are deliberately not named or described. They read the database directly, so the tables and columns are their contract; who runs which report is not a fact this collection carries. See consumption contracts for what that contract is.

What is out of scope by decision

Recorded so it is not re-litigated.

• No retrieval server and no import into another documentation system. See proposed machine retrieval.
• No .base files, no canvas, no embeds. The renderer supports wikilinks and this collection still authors relative links, for the reason in documentation maintenance.
• Field meanings are authored as data; the generated Markdown copy makes them readable without dictionary-page access. Hand-written prose explains the relationships. See field meaning.
• No live customer examples. Examples are synthetic.

Which vault skills this repository took

docs-kato ships eight skills. Three ideas transferred and five did not, recorded so the question is not reopened.

Access decisions

config/reference/userroles.json holds two roles: System administrator, which has everything, and Guest, which new users are auto-provisioned into.

Guest reads the whole docs module. Without that the collection would be readable by administrators alone, which would leave it unreachable by every department it was written for. The collection contains system explanations and synthetic examples. Production access is behind the proxy; local identity follows the development authorization configuration.

Guest does not reach dictionary/fields, because that page follows the dictionary module, which Guest does not reach. Guest can read the generated field reference in docs, but cannot inspect its live-schema coverage through that screen. The open decision concerns live-schema access; authored field meaning is already available in docs.

Both are permission facts in a reference/ file, so a change to either reaches production on the next deploy.

Open decisions

Recorded here rather than in a working file, because a decision nobody wrote down gets made again.

Related

• Documentation maintenance
• Documentation index
• Interfaces

Evidence

Screen claims are checked against app/http/ by checkdocs. Access statements are code-checked against config/reference/userroles.json, public/index.php and app/models/authorization.php. Commercial answers were supplied by the data owner and are cited in their concept pages. Field family scope is defined in app/models/dictionaryfields.php; it is not a full-database dictionary.