| 1 |
the repository's GitHub Discussions page |
https://github.com/zby/commonplace/discussions |
external |
|
|
Comments and counterexamples are welcome > on the repository's GitHub Discussions page. |
onward |
| 2 |
companion article |
kb/articles/the-software-house-as-the-unit-of-training.md |
article |
The Software House as the Unit of Training |
Doctrine that once an automated software house carries the production loop, project-specific continual learning runs over the whole house with the model as one update surface; training steps, write governance, explicit-… |
It does not argue that a fixed model is the best way to train such a house; a companion article takes that up. |
onward |
| 3 |
software house |
kb/notes/definitions/software-house.md |
definition-note |
Software house |
Definition — a software house is the complete persistent system responsible for developing and evolving software for external users |
The automated software house conjecture. At least one automated software house (below, the house) capable of open-ended coherent software change is practically reachable with LLMs available by 2026-09-02. |
A |
| 4 |
distributed-parametric state |
kb/notes/definitions/representational-form.md |
definition-note |
Representational form |
Definition - representational form classifies how an operative part is encoded and consumed: natural-language, symbolic, distributed-parametric, or mixed |
Together these are the distributed-parametric state. |
A |
| 5 |
notes and code |
kb/notes/definitions/representational-form.md |
definition-note |
Representational form |
Definition - representational form classifies how an operative part is encoded and consumed: natural-language, symbolic, distributed-parametric, or mixed |
What gets trained is the house, through changes that computation produces and the house retains in its notes and code. |
A |
| 6 |
definition |
kb/notes/definitions/software-house.md#scope |
definition-note |
Software house |
Definition — a software house is the complete persistent system responsible for developing and evolving software for external users |
An internal role is what the definition calls an internal production role: work the house depends on to produce the software, whoever performs it. |
A |
| 7 |
Holding a program theory means sustaining coherent search under delayed feedback |
kb/notes/program-theory-sustains-search-under-delayed-feedback.md |
note |
Holding a program theory means sustaining coherent search under delayed feedback |
Holding a program's theory is tested by whether a partial, fallible account of what the program is for keeps modification search, backtracking, and recovery coherent until delayed evidence arrives, not by whether the fi… |
Holding a program theory means sustaining coherent search under delayed feedback: the multi-tenant choice may not show its consequences until the next three demands arrive. |
B |
| 8 |
Naur's compiler case |
kb/sources/programming-as-theory-building.ingest.md |
source |
Ingest: Programming as Theory Building |
Naur's theory-building view makes maintainability depend on situated design understanding while bounding what retained rationale alone can transfer |
Naur's compiler case showed that full code, annotations, extensive design discussion, and personal advice did not give a successor team enough program-specific understanding. |
R |
| 9 |
one set of documents and one way of reading them, bounded to its time |
kb/notes/naurs-compiler-case-tests-one-historically-bounded-documentation-and-consumption-system.md |
note |
Naur's compiler case tests one historically bounded documentation-and-consumption system |
Naur's compiler transfer failure rules out more documentation of the same kind, but tested one historically bounded package and consumption process rather than every possible rationale, indexing, retrieval, and activati… |
But it tested one set of documents and one way of reading them, bounded to its time. |
B |
| 10 |
The distinction is between formal execution and explicitly formulated criteria |
kb/notes/naur-equates-machine-execution-with-formulated-criteria.md |
note |
Naur binds program theory to humans by equating machine execution with formulated criteria |
Naur argues program theory cannot be expressed as criteria, then concludes it is human-only; the bridge equates machine execution with formulated criteria, true for the programs of his day and separated since by trained… |
The distinction is between formal execution and explicitly formulated criteria. |
B |
| 11 |
Governing a behaviour-changing write therefore requires selection, validation, authorization, and coordination |
kb/notes/continual-learning-requires-governing-behaviour-changing-writes.md |
note |
Continual learning requires governing behaviour-changing writes, not just storing content |
For deployed systems, persistence is insufficient; continual learning must select, validate, authorize, and coordinate behaviour-changing updates across the representational forms a system can change |
Governing a behaviour-changing write therefore requires selection, validation, authorization, and coordination. |
B |
| 12 |
transition closure of the seed |
kb/articles/reachability-as-closure-under-the-seed-gate.md |
article |
Reachability as transition closure under the seed's successor relation |
Supplement to the reachability conjecture: an autonomous house's states form the transition closure of its seed under a state-dependent successor relation and declared input process; the Gödel-machine comparison differs… |
The companion article names this set the transition closure of the seed. |
A |
| 13 |
Gödel machine |
kb/notes/goedel-machines-are-a-proof-governed-case-of-self-modification.md |
note |
Gödel machines are a proof-governed case of reflective self-modification |
The Gödel machine realizes reflective self-modification with a proof-gated acceptance rule, gaining model-relative rigor at the cost of excluding useful changes it cannot prove |
The fully formal case is AI researcher Jürgen Schmidhuber's Gödel machine, a proof-governed construction that rewrites its own code. |
A |
| 14 |
Schmidhuber |
kb/sources/goedel-machines-schmidhuber.ingest.md |
source |
Ingest: Gödel Machines — Provably Optimal Self-Improvements |
Schmidhuber's Gödel machine — rewrite of any part of one's own code, proof searcher included, gated on a proof of higher axiomatized utility: the proof-governed case of reflective self-modification |
The paper states the price: the machine "must ignore those self-improvements whose effectiveness it cannot prove" (Schmidhuber, §2.4, verbatim). |
R |
| 15 |
third article |
kb/articles/bootstrapping-the-first-automated-software-house.md |
article |
Bootstrapping the First Automated Software House |
Research program for reaching the first automated software house from a human-agent house: move internal roles out of human hands one class at a time as their premises, criteria, and checks are built; evidence of a move… |
It has no witness run and is scored as a design target, not as evidence; the third article in this series sets out the program for getting from a house of that kind to a witness. |
onward |
| 16 |
companion map |
kb/articles/nearest-existing-constructions-to-a-reachability-witness.md |
article |
Nearest existing constructions to a reachability witness |
Comparison of reviewed self-improving systems against the reachability conjecture's four witness obligations, which do not fix which form carries the theory, with a separate stronger protocol for explicit retained theory |
The companion map compares twenty constructions and records the evidence behind each placement. |
onward |
| 17 |
companion article |
kb/articles/the-software-house-as-the-unit-of-training.md#testable-consequences |
article |
The Software House as the Unit of Training |
Doctrine that once an automated software house carries the production loop, project-specific continual learning runs over the whole house with the model as one update surface; training steps, write governance, explicit-… |
The companion article states it as a hypothesis with its own test. |
onward |
| 18 |
open-domain theory builder may itself become a software house |
kb/notes/an-open-domain-theory-builder-becomes-a-software-house-when-new-domains-require-production-machinery-changes.md |
note |
An open-domain theory builder becomes a software house when new domains require production-machinery changes |
A persistent automated theory builder for external users becomes a software house when genuinely new domains require it to revise the software that performs theory production rather than only the theories produced |
An open-domain theory builder may itself become a software house when new domains require changes to its production machinery. |
onward |
| 19 |
companion article |
kb/articles/the-software-house-as-the-unit-of-training.md |
article |
The Software House as the Unit of Training |
Doctrine that once an automated software house carries the production loop, project-specific continual learning runs over the whole house with the model as one update surface; training steps, write governance, explicit-… |
It does not argue that a fixed model is the best way to train such a house; a companion article takes that up. |
onward |