The technical appendix stands beside the base specification
The technical appendix describes how this repository builds the system — its stack, how each domain is built and how the user interface looks — in the detail an instance needs to repeat it; every part but it and the guidelines is the base specification.
It is no domain and stands at no level, beside the domains as contracts does, with a section for each domain it implements, under that domain's name, one for the stack, and, while any problem is set aside, one for its technical debt (§s-2r7k2aeyusgy6fw).
It never contradicts a rule of the base specification but extends and refines it: a rule too narrow for an implementation is widened in the base, its detail going to the technical appendix.
A node of the appendix describes how the nodes of the base specification it implements are to be carried out, in enough detail to be read only one way — exact values, examples and the edge cases of that implementation — and never restates what they state. Each of its nodes but a section, which requires nothing (§s-7445ahgjck2aefg), implements at least one node of the base specification, except a choice covering the whole system, which stands in the section of the stack, and except the technical debt (§s-2r7k2aeyusgy6fw).
An instance changes the technical appendix for itself, and what instances vary within it is a setting, described with its default.
The base specification stays stable while an implementation adapts to an instance's infrastructure and requirements, so only the technical appendix changes with an instance.
A part allowed to contradict the base would leave the base binding nowhere, since no rule could be relied on without reading the implementation too. Read beside the nodes it implements, an appendix node restating them would be a second copy, and a copy drifts from what it copies; how a rule is carried out has no other home, since the base names no technology, and described less exactly it would leave a choice to whoever implements it, which the code would then hold and the specification would not.
It is no subject area of the system but the way every one of them is built, which no level can place. A node bound to the rule it implements is found when that rule changes and is read beside it, and divided as the base is, the implementation of a rule is looked for in one place.
The problems set aside are read as one list, so they stand in one section, which spans the domains as the stack does, and a problem is not how a rule is carried out but where carrying it out falls short.
The repository holds nothing of any one instance, so what one instance chooses within the appendix is a setting, not a rule.
The links it makes
The links made to it
- refines ← The base specification holds no figure of one instance
- refines ← The technical debt holds the problems of the default implementation set aside
- cites ← What is checked, when, and what a failure costs
- cites ← How each check is made
- cites ← Where the types and runtime checks generated from the data records are written
The decisions taken on it
- Problem
The technical appendix had no stated place beside the domains, nothing said whether it could depart from the base specification, and its nodes were bound to no rule they implement.
- Ruling
The owner: the technical appendix stands outside the levels, as contracts does; it never contradicts the base specification but extends and refines it, a rule too narrow being widened in the base; every node implements a node of the base, the choices of the stack excepted; it is divided as the base is; this repository's appendix is the default implementation, an example each instance changes for itself, and it keeps its name, its being the default a detail.
- Problem
Nothing said what a node of the technical appendix holds beside the nodes it implements, and a draft retold the base rule it implemented while the values of its implementation had been moved into code.
- Ruling
The owner: a node of the appendix describes how the base nodes it implements are carried out, in enough detail to be read only one way — exact values, examples and edge cases — and never restates them, its links carrying what they state; the base answers what is done, the appendix how. Values taken from the code and a running instance while a project's existing documents are brought into the model are a departure recorded in the guide to adopting the method, not in the guidelines.
- Problem
The specification had no place for a problem of the implementation the owner set aside, so such a problem waited in the list of tasks as a task nobody meant to do.
- Ruling
The owner: the technical appendix holds a technical debt, one list of the problems of the implementation set aside, each only described as it stands; its standing there is the decision to set it aside.
- Problem
The rule had each node of the technical appendix implement a node of the base, its sections included, while a section requires nothing and the appendix's sections stand under the names of the domains they implement.
- Ruling
Following §s-7445ahgjck2aefg: a section of the technical appendix implements nothing; it stands under the name of the domain it implements.