Complete ASSEMBLY-WP-0002: promote organism-lens concepts, add Network Object Model
- MembraneModel, SeedKernel, EvolutionModel, MetabolismModel, ResourceOntology promoted verbatim from history/ with originating questions - NetworkObjectModel.md: implementation-neutral object model with invariants - Cross-lens notes applied from Glossary.md (T09) Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Assistant: claude-code Assistant-Model: opus Assistant-Process: 1494246@bnt-lap001 Assistant-Session: caf6de6f-f9e4-47ce-a584-49baa271fa4b
This commit is contained in:
parent
73bb8fbf16
commit
08be42f65d
12 changed files with 3088 additions and 29 deletions
|
|
@ -2,19 +2,11 @@
|
|||
# Custodian Brief — assembly-economics
|
||||
|
||||
**Domain:** communication
|
||||
**Last synced:** 2026-10-11 22:22 UTC
|
||||
**Last synced:** 2026-10-11 22:34 UTC
|
||||
**State Hub:** http://127.0.0.1:8000 *(adjust if running on a remote machine)*
|
||||
|
||||
## Active Workstreams
|
||||
|
||||
### Bootstrap State Hub integration
|
||||
Progress: 0/3 done | workplan_id: `151e554e-341a-50a1-89f5-4cd17e66cc83`
|
||||
|
||||
**Open tasks:**
|
||||
- · Review Generated Integration Files `cff10994`
|
||||
- · Verify Local Developer Workflow `19d7dd71`
|
||||
- · Seed First Real Workplan `deb2bd45`
|
||||
|
||||
### Promote exploration concepts into concepts/
|
||||
Progress: 2/9 done | workplan_id: `2af40c6f-7b17-5f78-be0c-e0d151bd8f38`
|
||||
|
||||
|
|
|
|||
|
|
@ -8,13 +8,13 @@
|
|||
|
||||
| Kind | ID | Status | Lane | Source |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| workplan | ASSEMBLY-WP-0001 | ready | — | workplans/ASSEMBLY-WP-0001-statehub-bootstrap.md |
|
||||
| workplan | ASSEMBLY-WP-0001 | finished | — | workplans/ASSEMBLY-WP-0001-statehub-bootstrap.md |
|
||||
| workplan | ASSEMBLY-WP-0002 | active | — | workplans/ASSEMBLY-WP-0002-concept-promotion.md |
|
||||
| workplan | ASSEMBLY-WP-0003 | finished | — | workplans/ASSEMBLY-WP-0003-seed-integration.md |
|
||||
| workplan | ASSEMBLY-WP-0004 | proposed | — | workplans/ASSEMBLY-WP-0004-gadm-0.2-modeling.md |
|
||||
| task | ASSEMBLY-WP-0001-T01 | todo | — | workplans/ASSEMBLY-WP-0001-statehub-bootstrap.md |
|
||||
| task | ASSEMBLY-WP-0001-T02 | todo | — | workplans/ASSEMBLY-WP-0001-statehub-bootstrap.md |
|
||||
| task | ASSEMBLY-WP-0001-T03 | todo | — | workplans/ASSEMBLY-WP-0001-statehub-bootstrap.md |
|
||||
| task | ASSEMBLY-WP-0001-T01 | done | — | workplans/ASSEMBLY-WP-0001-statehub-bootstrap.md |
|
||||
| task | ASSEMBLY-WP-0001-T02 | done | — | workplans/ASSEMBLY-WP-0001-statehub-bootstrap.md |
|
||||
| task | ASSEMBLY-WP-0001-T03 | done | — | workplans/ASSEMBLY-WP-0001-statehub-bootstrap.md |
|
||||
| task | ASSEMBLY-WP-0002-T01 | done | — | workplans/ASSEMBLY-WP-0002-concept-promotion.md |
|
||||
| task | ASSEMBLY-WP-0002-T02 | done | — | workplans/ASSEMBLY-WP-0002-concept-promotion.md |
|
||||
| task | ASSEMBLY-WP-0002-T03 | todo | — | workplans/ASSEMBLY-WP-0002-concept-promotion.md |
|
||||
|
|
|
|||
|
|
@ -891,3 +891,24 @@ ExperimentProtocol.md
|
|||
```
|
||||
|
||||
The immediate next useful artifact is probably `NetworkObjectModel.md`, translating the conceptual entities defined here into a precise executable object model while deliberately remaining independent of implementation language or storage technology.
|
||||
|
||||
---
|
||||
|
||||
## Appendix — Cross-lens notes
|
||||
|
||||
Added 2026-10-12 under ASSEMBLY-WP-0002-T09, applying `Glossary.md`. These
|
||||
notes connect this concept with the society lens and do not change the
|
||||
sections above.
|
||||
|
||||
- **Chunks are assemblies at organism scale (§ 18).** In cross-lens or
|
||||
societal statements, use *assembly*. *Chunk* remains the name of the
|
||||
internal mechanism.
|
||||
- **Observers are selection mechanisms (§ 13).** Use *selection* for the
|
||||
process and *observer* for the entity performing it.
|
||||
- **Viability variables (§ 16)** correspond to GADM stock floors.
|
||||
Constitutional floors are non-tradeable (see `NetworkObjectModel.md` § 6.4).
|
||||
- **Action states (§ 12) and agency.** Organisms have *action repertoires*,
|
||||
not agency. *Agency* is reserved for humans and groups. The gap between
|
||||
*possible* and *permitted* is where domination operates at society scale.
|
||||
- **Forgetting (§ 31) is disassembly** at organism scale.
|
||||
- The precise object model for this concept is `NetworkObjectModel.md`.
|
||||
|
|
|
|||
464
concepts/EvolutionModel.md
Normal file
464
concepts/EvolutionModel.md
Normal file
|
|
@ -0,0 +1,464 @@
|
|||
<!--
|
||||
Provenance: promoted verbatim from history/20261011-InitialExploration.md
|
||||
(lines 2438–2875, conversation dated 2026-10-06), including the originating
|
||||
question(s). Promoted 2026-10-12 under ASSEMBLY-WP-0002-T05. Consolidation
|
||||
happens in later commits; history/ keeps the original.
|
||||
Terminology edit: "canonical" was replaced with "standard". The project
|
||||
reserves "canon" for an established body of knowledge.
|
||||
-->
|
||||
|
||||
# Evolution Model
|
||||
|
||||
**Status:** Concept v0.1, exploratory. Part of the information-organism lens (INTENT.md, Two Lenses).
|
||||
|
||||
---
|
||||
|
||||
**Originating question:**
|
||||
|
||||
> Now envision those systems as organizms that we can organize in an evolutionary sense with mutation and recombination accross generations. Based on the kernel it should be possible to establish and evolved predefined systems for different environments and initial purposes. So the concept potentially allows for the generation of very generic information system problem solvers.
|
||||
|
||||
Yes. At that point the architecture stops being merely a self-developing information organism and becomes an **evolvable population of information organisms**.
|
||||
|
||||
The most interesting consequence is that we no longer have to choose between a completely generic seed and a heavily engineered application. We can instead let useful intermediate forms emerge and preserve them as **heritable lineages**.
|
||||
|
||||
```text
|
||||
generic kernel
|
||||
↓
|
||||
development in environment
|
||||
↓
|
||||
specialized organism
|
||||
↓
|
||||
evaluation
|
||||
↓
|
||||
selection
|
||||
↓
|
||||
mutation / recombination
|
||||
↓
|
||||
new generation
|
||||
```
|
||||
|
||||
### 1. Genotype versus phenotype
|
||||
|
||||
Three layers:
|
||||
|
||||
```text
|
||||
Kernel
|
||||
↓
|
||||
Genotype
|
||||
↓
|
||||
Phenotype
|
||||
```
|
||||
|
||||
**Kernel**
|
||||
|
||||
The almost immutable machinery:
|
||||
|
||||
```text
|
||||
observe
|
||||
remember
|
||||
predict
|
||||
act
|
||||
allocate resources
|
||||
learn
|
||||
adapt
|
||||
reproduce
|
||||
```
|
||||
|
||||
**Genotype**
|
||||
|
||||
A heritable developmental configuration.
|
||||
|
||||
**Phenotype**
|
||||
|
||||
The actual organism after interacting with an environment.
|
||||
|
||||
\[
|
||||
P = Develop(G,E)
|
||||
\]
|
||||
|
||||
The same genotype can develop differently in different organizations.
|
||||
|
||||
### 2. Breed systems rather than merely configure them
|
||||
|
||||
Different populations may emerge for:
|
||||
|
||||
```text
|
||||
Document Operations
|
||||
Customer Service
|
||||
Security Operations
|
||||
Software Engineering
|
||||
Financial Operations
|
||||
Supply Chain
|
||||
Knowledge Management
|
||||
```
|
||||
|
||||
Specialization is evolutionary rather than architectural fragmentation.
|
||||
|
||||
### 3. Recombination
|
||||
|
||||
A document-understanding organism and a temporal-process reasoning organism may produce offspring inheriting capabilities from both.
|
||||
|
||||
This suggests a modular genotype composed of **Traits**.
|
||||
|
||||
Examples:
|
||||
|
||||
```text
|
||||
anomaly-sensitive
|
||||
graph-centric-memory
|
||||
cautious-actuation
|
||||
sparse-semantic-chunking
|
||||
active-human-teaching
|
||||
document-heavy-environment
|
||||
```
|
||||
|
||||
### 4. Inheritance of learned structures
|
||||
|
||||
Possible forms of inheritance:
|
||||
|
||||
- Genetic inheritance
|
||||
- Epigenetic inheritance
|
||||
- Cultural inheritance
|
||||
- Episodic inheritance
|
||||
|
||||
An offspring may inherit how to learn, what usually matters, what others have learned, and selected examples.
|
||||
|
||||
### 5. Optimize developmental potential
|
||||
|
||||
Fitness should include:
|
||||
|
||||
\[
|
||||
F =
|
||||
f(
|
||||
performance,
|
||||
resourceEfficiency,
|
||||
adaptability,
|
||||
transferability,
|
||||
robustness,
|
||||
safety,
|
||||
developmentSpeed
|
||||
)
|
||||
\]
|
||||
|
||||
The most interesting trait may be the ability to become useful in unfamiliar environments quickly and cheaply.
|
||||
|
||||
### 6. Two timescales of adaptation
|
||||
|
||||
Within lifetime:
|
||||
|
||||
```text
|
||||
learning
|
||||
```
|
||||
|
||||
Across generations:
|
||||
|
||||
```text
|
||||
evolution
|
||||
```
|
||||
|
||||
Potentially compressed into minutes, hours, days, and weeks.
|
||||
|
||||
### 7. Third timescale: ecosystem evolution
|
||||
|
||||
Multiple organisms may specialize and cooperate.
|
||||
|
||||
Selection may favor cooperative compatibility.
|
||||
|
||||
### 8. Reproduction should be explicit
|
||||
|
||||
```text
|
||||
parent phenotype
|
||||
↓
|
||||
extract heritable state
|
||||
↓
|
||||
produce genotype
|
||||
↓
|
||||
mutation / crossover
|
||||
↓
|
||||
candidate child
|
||||
↓
|
||||
sandbox development
|
||||
↓
|
||||
evaluation
|
||||
↓
|
||||
promotion
|
||||
```
|
||||
|
||||
Production organisms can remain stable while descendants are tested.
|
||||
|
||||
### 9. Evolutionary loop
|
||||
|
||||
```text
|
||||
Population
|
||||
│
|
||||
▼
|
||||
instantiate
|
||||
│
|
||||
▼
|
||||
environments
|
||||
│
|
||||
▼
|
||||
develop
|
||||
│
|
||||
▼
|
||||
evaluate
|
||||
│
|
||||
┌───────┴────────┐
|
||||
▼ ▼
|
||||
survive retire
|
||||
│
|
||||
▼
|
||||
reproduce
|
||||
│
|
||||
┌─────┴───────┐
|
||||
▼ ▼
|
||||
mutation recombination
|
||||
└─────┬───────┘
|
||||
▼
|
||||
next generation
|
||||
```
|
||||
|
||||
### 10. Mutation levels
|
||||
|
||||
- Parameter mutation
|
||||
- Strategy mutation
|
||||
- Structural mutation
|
||||
- Developmental mutation
|
||||
|
||||
Developmental mutation changes the rule that determines how structure develops.
|
||||
|
||||
### 11. Recombination should respect interfaces
|
||||
|
||||
Blind crossover is poor for software.
|
||||
|
||||
Recombination should happen across stable interfaces.
|
||||
|
||||
This implies something analogous to a **developmental ABI**.
|
||||
|
||||
### 12. Fitness needs environments, not benchmarks alone
|
||||
|
||||
Evaluate in an ecology of environments:
|
||||
|
||||
```text
|
||||
quiet enterprise
|
||||
high-volume enterprise
|
||||
messy legacy enterprise
|
||||
strictly regulated enterprise
|
||||
rapidly changing startup
|
||||
adversarial environment
|
||||
resource-constrained environment
|
||||
```
|
||||
|
||||
### 13. Generalists and specialists should coexist
|
||||
|
||||
The repository of genotypes becomes a **phylogenetic library of information systems**.
|
||||
|
||||
### 14. Analogy to software distributions
|
||||
|
||||
```text
|
||||
Information Kernel
|
||||
↓
|
||||
evolved lineage
|
||||
↓
|
||||
deployed seed
|
||||
↓
|
||||
development in environment
|
||||
↓
|
||||
local organism
|
||||
```
|
||||
|
||||
So:
|
||||
|
||||
```text
|
||||
kernel
|
||||
lineage
|
||||
individual
|
||||
```
|
||||
|
||||
could become standard levels.
|
||||
|
||||
### 15. The generic problem solver appears through evolution
|
||||
|
||||
Generality emerges by selecting for:
|
||||
|
||||
```text
|
||||
rapid environmental understanding
|
||||
problem decomposition
|
||||
useful abstraction
|
||||
efficient experimentation
|
||||
effective resource use
|
||||
good transfer
|
||||
safe action
|
||||
learning from feedback
|
||||
```
|
||||
|
||||
### 16. Artificial “species”
|
||||
|
||||
A species could be a population with compatible genotype interfaces and sufficiently similar developmental machinery.
|
||||
|
||||
### 17. Evolutionary inheritance should include failures
|
||||
|
||||
Lineages may inherit:
|
||||
|
||||
```text
|
||||
known failure modes
|
||||
forbidden strategies
|
||||
bad hypotheses
|
||||
expensive dead ends
|
||||
```
|
||||
|
||||
This enables cumulative negative knowledge.
|
||||
|
||||
### 18. Resource economics becomes selection pressure
|
||||
|
||||
An organism receives:
|
||||
|
||||
```text
|
||||
objectives
|
||||
budget
|
||||
```
|
||||
|
||||
and selection naturally rewards useful outcome per resource consumed.
|
||||
|
||||
Human attention can also be priced as a scarce resource.
|
||||
|
||||
### 19. Fitness must be multi-dimensional
|
||||
|
||||
Possible dimensions:
|
||||
|
||||
```text
|
||||
objective_performance
|
||||
resource_efficiency
|
||||
adaptability
|
||||
robustness
|
||||
transferability
|
||||
human_attention_cost
|
||||
safety
|
||||
explainability
|
||||
```
|
||||
|
||||
### 20. Hard constraints should remain outside evolutionary optimization
|
||||
|
||||
Examples:
|
||||
|
||||
```text
|
||||
tenant isolation
|
||||
credential boundaries
|
||||
legal retention
|
||||
root authority
|
||||
maximum expenditure
|
||||
```
|
||||
|
||||
Evolution optimizes inside the safe envelope.
|
||||
|
||||
### 21. Compact model
|
||||
|
||||
\[
|
||||
I = (K,G,P,E)
|
||||
\]
|
||||
|
||||
Development:
|
||||
|
||||
\[
|
||||
P = D(K,G,\mathcal{E})
|
||||
\]
|
||||
|
||||
Evaluation:
|
||||
|
||||
\[
|
||||
F = Evaluate(P,\mathcal{E},C)
|
||||
\]
|
||||
|
||||
Reproduction:
|
||||
|
||||
\[
|
||||
G' = R(G_1,G_2,\mu)
|
||||
\]
|
||||
|
||||
### 22. Four nested loops
|
||||
|
||||
**Activation loop**
|
||||
|
||||
```text
|
||||
observe → activate → respond
|
||||
```
|
||||
|
||||
**Learning loop**
|
||||
|
||||
```text
|
||||
experience → update internal model
|
||||
```
|
||||
|
||||
**Development loop**
|
||||
|
||||
```text
|
||||
environment → phenotype specialization
|
||||
```
|
||||
|
||||
**Evolution loop**
|
||||
|
||||
```text
|
||||
population → selection → reproduction
|
||||
```
|
||||
|
||||
Possibly an ecosystem loop:
|
||||
|
||||
```text
|
||||
species ↔ species
|
||||
organization ↔ organisms
|
||||
```
|
||||
|
||||
### 23. Ecosystem architecture
|
||||
|
||||
```text
|
||||
Genome Library
|
||||
│
|
||||
┌─────────────┼─────────────┐
|
||||
▼ ▼ ▼
|
||||
lineage A lineage B lineage C
|
||||
│ │ │
|
||||
└──────┬──────┴──────┬──────┘
|
||||
│ reproduction
|
||||
▼
|
||||
Seeds
|
||||
│
|
||||
deploy into environment
|
||||
▼
|
||||
Organisms
|
||||
│
|
||||
live / learn
|
||||
│
|
||||
▼
|
||||
Fitness Evidence
|
||||
│
|
||||
▼
|
||||
Selection
|
||||
│
|
||||
└──────────────► Genome Library
|
||||
```
|
||||
|
||||
The concept becomes:
|
||||
|
||||
> **a hereditary developmental substrate for information-processing organisms that attach to environments, receive purpose and resources, develop internal semantic structures, learn useful behaviors, and contribute their successful adaptations to evolving lineages.**
|
||||
|
||||
Foundational concepts:
|
||||
|
||||
```text
|
||||
Seed — minimally viable developmental kernel
|
||||
Organism — developed individual coupled to an environment
|
||||
Lineage — heritable sequence of related developmental configurations
|
||||
Ecology — interacting organisms, environments, resources and selection pressures
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Appendix — Cross-lens notes
|
||||
|
||||
Added 2026-10-12 under ASSEMBLY-WP-0002-T09, applying `Glossary.md`.
|
||||
|
||||
- **Developmental potential is generativity** applied to one organism's
|
||||
future. Use *generativity* in cross-lens statements.
|
||||
- **Fitness.** Within this organism-lens document, *fitness* is acceptable
|
||||
because it is explicitly multi-dimensional (§ 19). In societal contexts,
|
||||
prefer *selection quality*, to avoid a single-score connotation.
|
||||
- **Inheritance and distributions** (§§ 4, 14) are commons when lineages are
|
||||
openly inheritable, and enclosure when they are closed.
|
||||
|
|
@ -769,3 +769,24 @@ It does not claim that:
|
|||
- or the underlying scientific concept of Assembly Theory must be accepted for this framework to remain useful.
|
||||
|
||||
The next step is to formalize the dynamic relationships and test the ideas through explicit models.
|
||||
|
||||
---
|
||||
|
||||
## Appendix — Cross-lens notes
|
||||
|
||||
Added 2026-10-12 under ASSEMBLY-WP-0002-T09, applying `Glossary.md`. These
|
||||
notes connect this concept with the information-organism lens and do not change
|
||||
the sections above.
|
||||
|
||||
- **Power (§ 13): two further domination channels.** *Membrane control*
|
||||
(who configures what information organisms sense and do) and *lineage
|
||||
concentration* (ownership of the organism lineages that learn from the most
|
||||
use). See `../models/InformationOrganismsInGADM.md` § 3.5.
|
||||
- **Commons (§ 17).** An openly inheritable organism lineage is part of the
|
||||
assembly commons. A closed one is enclosure.
|
||||
- **Agency (§ 7)** is reserved for humans and groups. Information organisms
|
||||
have action repertoires, consistent with "learning is distinct from
|
||||
authority".
|
||||
- **Attention.** This concept lists attention among non-abundant resources.
|
||||
`ResourceOntology.md` develops it as lived capacity, the reference scarce
|
||||
resource.
|
||||
|
|
|
|||
657
concepts/MembraneModel.md
Normal file
657
concepts/MembraneModel.md
Normal file
|
|
@ -0,0 +1,657 @@
|
|||
<!--
|
||||
Provenance: promoted verbatim from history/20261011-InitialExploration.md
|
||||
(lines 1743–2063, 2878–3201, conversation dated 2026-10-06), including the originating
|
||||
question(s). Promoted 2026-10-12 under ASSEMBLY-WP-0002-T03. Consolidation
|
||||
happens in later commits; history/ keeps the original.
|
||||
-->
|
||||
|
||||
# Membrane Model
|
||||
|
||||
**Status:** Concept v0.1, exploratory. Part of the information-organism lens (INTENT.md, Two Lenses).
|
||||
|
||||
---
|
||||
|
||||
## Part I — The interface membrane to institutional IT
|
||||
|
||||
**Originating question:**
|
||||
|
||||
> Before introducing more artefacts, let's think about how a system like this can be integrated with a classic it environment of a company. There are actual artefacts and many of them in a company and they are organized and archived in many it systems according to existing governance rules. It will be essential for practicability to establish a good interface membrane between what we discuss here and the original data entities.
|
||||
|
||||
Yes. I think this interface membrane is not a peripheral integration concern; it is one of the core architectural boundaries of the whole idea.
|
||||
|
||||
The adaptive network should **not become another system of record**. It should sit above the existing operational landscape as a learning and interpretive layer, while the authoritative business artefacts remain governed by their original systems.
|
||||
|
||||
A useful name is:
|
||||
|
||||
> **Semantic Membrane**
|
||||
|
||||
Its purpose is to translate between the messy, heterogeneous, governed world of enterprise IT and the comparatively clean semantic world of the adaptive network.
|
||||
|
||||
The core architectural rule would be:
|
||||
|
||||
> **Reference the original artefact, project only what is needed, preserve provenance and authority, and never confuse the learned representation with the authoritative source.**
|
||||
|
||||
### 1. Two worlds
|
||||
|
||||
On the enterprise side you have things like:
|
||||
|
||||
```text
|
||||
SAP invoice
|
||||
SharePoint document
|
||||
CRM customer
|
||||
Active Directory user
|
||||
HR employee record
|
||||
Jira ticket
|
||||
email
|
||||
PDF
|
||||
database row
|
||||
API object
|
||||
machine telemetry
|
||||
physical shipment
|
||||
```
|
||||
|
||||
On the network side:
|
||||
|
||||
```text
|
||||
Invoice
|
||||
Customer
|
||||
EmployeeRole
|
||||
Supplier
|
||||
Contract
|
||||
Incident
|
||||
WorkstationClass
|
||||
```
|
||||
|
||||
plus activations, associations, predictions and learned relationships.
|
||||
|
||||
The membrane connects these worlds without pretending they are identical.
|
||||
|
||||
### 2. Do not ingest objects directly — create semantic projections
|
||||
|
||||
Introduce:
|
||||
|
||||
> **Projection**
|
||||
|
||||
```text
|
||||
Source Artefact
|
||||
↓
|
||||
Semantic Projection
|
||||
↓
|
||||
Network Token / Activation
|
||||
```
|
||||
|
||||
The projection contains only the information relevant for the adaptive network.
|
||||
|
||||
### 3. Identity must survive the membrane
|
||||
|
||||
Every projected object should retain a durable link back to its authoritative origin.
|
||||
|
||||
Distinguish:
|
||||
|
||||
```text
|
||||
source identity
|
||||
semantic identity
|
||||
instance identity
|
||||
```
|
||||
|
||||
Identity resolution itself should be explicit, probabilistic where necessary, and auditable.
|
||||
|
||||
### 4. Authority stays outside the network
|
||||
|
||||
A crucial invariant:
|
||||
|
||||
```text
|
||||
semantic representation ≠ authoritative state
|
||||
```
|
||||
|
||||
The network may infer something while the enterprise system records something else.
|
||||
|
||||
A useful information classification:
|
||||
|
||||
```text
|
||||
OBSERVED
|
||||
DECLARED
|
||||
INFERRED
|
||||
PREDICTED
|
||||
PROPOSED
|
||||
AUTHORITATIVE
|
||||
```
|
||||
|
||||
### 5. The membrane should be bidirectional, but asymmetrical
|
||||
|
||||
Inbound:
|
||||
|
||||
```text
|
||||
Enterprise System
|
||||
↓
|
||||
observe / subscribe / query
|
||||
↓
|
||||
normalize
|
||||
↓
|
||||
semantic projection
|
||||
↓
|
||||
network activation
|
||||
```
|
||||
|
||||
Outbound:
|
||||
|
||||
```text
|
||||
Network
|
||||
↓
|
||||
recommendation / proposed action
|
||||
↓
|
||||
policy & authority check
|
||||
↓
|
||||
adapter
|
||||
↓
|
||||
Enterprise System
|
||||
```
|
||||
|
||||
Reading and learning can be relatively permissive.
|
||||
|
||||
Acting should require explicit authority.
|
||||
|
||||
### 6. Five membrane functions
|
||||
|
||||
```text
|
||||
1. Observe
|
||||
2. Identify
|
||||
3. Project
|
||||
4. Govern
|
||||
5. Actuate
|
||||
```
|
||||
|
||||
### 7. Artefact vs representation
|
||||
|
||||
Distinguish:
|
||||
|
||||
```text
|
||||
Artefact
|
||||
Representation
|
||||
Claim
|
||||
```
|
||||
|
||||
Claims retain provenance.
|
||||
|
||||
### 8. The membrane should be claim-oriented
|
||||
|
||||
A claim may specify subject, predicate, object, source, authority, observed time, and confidence.
|
||||
|
||||
This allows contradictions without corrupting the model.
|
||||
|
||||
### 9. Preserve the original governance envelope
|
||||
|
||||
Objects enter the semantic network carrying restrictions such as data classification, tenant, owner, retention, purpose, and allowed processing.
|
||||
|
||||
Derived knowledge may inherit restrictions.
|
||||
|
||||
### 10. Learning must not destroy provenance
|
||||
|
||||
Learned relationships should retain evidence such as episode counts, source period, tenant, and confidence.
|
||||
|
||||
### 11. Historical state matters
|
||||
|
||||
Mutable business objects should become observations of temporal state transitions rather than just snapshots.
|
||||
|
||||
### 12. Read models rather than replicas
|
||||
|
||||
The network stores enough information to reason, not enough to become a replacement source system.
|
||||
|
||||
### 13. Lazy materialization
|
||||
|
||||
Semantic representation can be built on demand.
|
||||
|
||||
### 14. The membrane becomes a sensory and motor system
|
||||
|
||||
Inbound:
|
||||
|
||||
```text
|
||||
source artefact
|
||||
↓
|
||||
sensor
|
||||
↓
|
||||
semantic activation
|
||||
```
|
||||
|
||||
Outbound:
|
||||
|
||||
```text
|
||||
selected action
|
||||
↓
|
||||
motor adapter
|
||||
↓
|
||||
enterprise change
|
||||
```
|
||||
|
||||
### 15. Epistemic boundary
|
||||
|
||||
The network never sees reality directly.
|
||||
|
||||
It sees observations produced by interfaces.
|
||||
|
||||
Missing data can mean false, unknown, not observed, not accessible, not projected, or not retained.
|
||||
|
||||
### 16. Adaptive membrane only carefully
|
||||
|
||||
Some parts can learn:
|
||||
|
||||
```text
|
||||
schema mappings
|
||||
entity matching
|
||||
semantic extraction
|
||||
source reliability
|
||||
```
|
||||
|
||||
Other parts should remain deterministic:
|
||||
|
||||
```text
|
||||
authorization
|
||||
tenant isolation
|
||||
retention enforcement
|
||||
write permissions
|
||||
source-system contracts
|
||||
```
|
||||
|
||||
### 17. SourceBinding
|
||||
|
||||
A useful conceptual object:
|
||||
|
||||
```yaml
|
||||
SourceBinding:
|
||||
semantic_entity: Invoice
|
||||
source_system: SAP
|
||||
source_type: AccountingDocument
|
||||
identity_mapping: ...
|
||||
projection_rule: ...
|
||||
access_policy: ...
|
||||
freshness_policy: ...
|
||||
write_capabilities: ...
|
||||
```
|
||||
|
||||
### 18. Evidence
|
||||
|
||||
Every semantic assertion entering the network should ideally be backed by evidence.
|
||||
|
||||
### 19. Conceptual architecture
|
||||
|
||||
```text
|
||||
┌────────────────────────────────────────────┐
|
||||
│ EXISTING ENTERPRISE SYSTEMS │
|
||||
│ ERP CRM DMS IAM HR DB Email APIs Files ... │
|
||||
└─────────────────────┬──────────────────────┘
|
||||
│
|
||||
▼
|
||||
╔════════════════════════════════════════════╗
|
||||
║ SEMANTIC MEMBRANE ║
|
||||
║ observation ║
|
||||
║ identity resolution ║
|
||||
║ provenance ║
|
||||
║ semantic projection ║
|
||||
║ policy enforcement ║
|
||||
║ data minimization ║
|
||||
║ temporalization ║
|
||||
║ source binding ║
|
||||
║--------------------------------------------║
|
||||
║ deterministic authority / write boundary ║
|
||||
╚═══════════════════╤════════════════════════╝
|
||||
│
|
||||
▼
|
||||
┌────────────────────────────────────────────┐
|
||||
│ ADAPTIVE INFORMATION PROCESSING NETWORK │
|
||||
│ activation │
|
||||
│ prediction │
|
||||
│ association │
|
||||
│ goals │
|
||||
│ learning │
|
||||
│ chunking │
|
||||
└─────────────────────┬──────────────────────┘
|
||||
│
|
||||
▼
|
||||
╔════════════════════════════════════════════╗
|
||||
║ AUTHORITY / ACTUATION GATE ║
|
||||
╚═══════════════════╤════════════════════════╝
|
||||
│
|
||||
▼
|
||||
ENTERPRISE SYSTEMS
|
||||
```
|
||||
|
||||
The key invariant:
|
||||
|
||||
> **The adaptive network operates on semantic representations and evidence, not on authoritative enterprise artefacts themselves. Enterprise systems retain ownership of authoritative state; the membrane preserves identity, provenance, governance and controlled actuation between both worlds.**
|
||||
|
||||
The target is not:
|
||||
|
||||
```text
|
||||
integrate all enterprise data
|
||||
```
|
||||
|
||||
but:
|
||||
|
||||
```text
|
||||
make selected enterprise reality
|
||||
semantically observable and safely actionable.
|
||||
```
|
||||
|
||||
## Part II — The membrane as information filter and control interface
|
||||
|
||||
**Originating question:**
|
||||
|
||||
> One final idea to close out this initial exploration of the concept. A very important aspect for such systems is the membrane between the system and its environment. The membrane is an information filter and needs to reduce the vast amount of information potentially available in the environment to what the system effectively samples or accepts as events triggering internal information flows. Establishing and manageing this membrane may be the most relevant control interface to make such an organizm a useful reusable tool or toolkit.
|
||||
|
||||
Yes. I think that closes the initial exploration around the right center.
|
||||
|
||||
The membrane is not merely an integration layer. It is the **organism’s effective sensorium, attention boundary, and action boundary**. In practice, it may be more important than the internal learning machinery because it determines what world the organism is even capable of perceiving.
|
||||
|
||||
A useful formulation is:
|
||||
|
||||
> **An information organism is defined at least as much by what it can perceive and act upon as by how it processes what it perceives.**
|
||||
|
||||
### The membrane as information filter
|
||||
|
||||
```text
|
||||
potentially observable information
|
||||
↓
|
||||
accessibility
|
||||
↓
|
||||
sampling
|
||||
↓
|
||||
selection
|
||||
↓
|
||||
projection
|
||||
↓
|
||||
event formation
|
||||
↓
|
||||
internal activation
|
||||
```
|
||||
|
||||
The membrane creates an intentional **information bottleneck**.
|
||||
|
||||
Without it, the organism wastes compute, learns irrelevant correlations, becomes harder to govern, and risks crossing information boundaries.
|
||||
|
||||
### The membrane determines the organism's Umwelt
|
||||
|
||||
Two organisms can inhabit the same enterprise but experience radically different worlds.
|
||||
|
||||
A security organism might perceive authentication events, network connections, privilege changes, configuration changes, and security alerts.
|
||||
|
||||
A customer-service organism might perceive customer messages, orders, support cases, contracts, response times, and sentiment.
|
||||
|
||||
Their membranes define different **organizational Umwelten**.
|
||||
|
||||
### Membrane configuration becomes the primary deployment interface
|
||||
|
||||
Configure:
|
||||
|
||||
```text
|
||||
what it may see
|
||||
what it should notice
|
||||
what it may ask for
|
||||
what it may retain
|
||||
what it may infer
|
||||
what it may act upon
|
||||
```
|
||||
|
||||
This may shape behavior more strongly than internal business logic.
|
||||
|
||||
### Bidirectional membrane
|
||||
|
||||
The perceptual side asks:
|
||||
|
||||
> What is allowed to become an internal event?
|
||||
|
||||
The actuation side asks:
|
||||
|
||||
> What internal intentions are allowed to become environmental events?
|
||||
|
||||
Together they define the organism's **effective agency**.
|
||||
|
||||
### Filtering should happen before expensive cognition
|
||||
|
||||
Prefer:
|
||||
|
||||
```text
|
||||
everything
|
||||
↓
|
||||
deterministic coarse filter
|
||||
↓
|
||||
cheap semantic filter
|
||||
↓
|
||||
adaptive attention
|
||||
↓
|
||||
expensive cognition
|
||||
```
|
||||
|
||||
The membrane becomes part of the organism's economics.
|
||||
|
||||
### The membrane should be layered
|
||||
|
||||
#### Constitutional membrane
|
||||
|
||||
Hard boundaries:
|
||||
|
||||
```text
|
||||
tenant isolation
|
||||
legal restrictions
|
||||
credentials
|
||||
forbidden sources
|
||||
maximum action authority
|
||||
privacy
|
||||
```
|
||||
|
||||
#### Operational membrane
|
||||
|
||||
Configured scope:
|
||||
|
||||
```text
|
||||
which systems
|
||||
which object types
|
||||
which topics
|
||||
which event streams
|
||||
which actions
|
||||
```
|
||||
|
||||
#### Adaptive membrane
|
||||
|
||||
Learned relevance:
|
||||
|
||||
```text
|
||||
this supplier is currently interesting
|
||||
this event class rarely matters
|
||||
this pattern predicts failure
|
||||
```
|
||||
|
||||
#### Ephemeral membrane
|
||||
|
||||
Current attention.
|
||||
|
||||
Each inner layer can narrow the world further but must not bypass outer layers.
|
||||
|
||||
### Sampling becomes an explicit action
|
||||
|
||||
Observing additional information consumes resources.
|
||||
|
||||
A membrane interaction can itself be an action:
|
||||
|
||||
```text
|
||||
inspect document
|
||||
query database
|
||||
retrieve history
|
||||
open attachment
|
||||
ask human
|
||||
subscribe to event stream
|
||||
```
|
||||
|
||||
Perception becomes **active perception**.
|
||||
|
||||
### Membrane evolution may be more important than internal evolution
|
||||
|
||||
Much of evolved intelligence could manifest as:
|
||||
|
||||
> **better selection of what deserves processing.**
|
||||
|
||||
The intelligence problem is partly:
|
||||
|
||||
```text
|
||||
what should I think about?
|
||||
```
|
||||
|
||||
before it is:
|
||||
|
||||
```text
|
||||
how should I think about it?
|
||||
```
|
||||
|
||||
### Habituation and sensitization
|
||||
|
||||
**Habituation**
|
||||
|
||||
Repeated low-value events produce progressively less activation.
|
||||
|
||||
**Sensitization**
|
||||
|
||||
Events associated with significant outcomes receive increased future attention.
|
||||
|
||||
### Learned filtering danger
|
||||
|
||||
If the organism stops sampling a region, it may become blind to change.
|
||||
|
||||
So the membrane needs controlled exploration.
|
||||
|
||||
### Negative space must remain visible
|
||||
|
||||
The organism must distinguish:
|
||||
|
||||
```text
|
||||
nothing happened
|
||||
```
|
||||
|
||||
from:
|
||||
|
||||
```text
|
||||
I did not observe that region
|
||||
```
|
||||
|
||||
Internal knowledge needs observation metadata such as:
|
||||
|
||||
```text
|
||||
observed
|
||||
unobserved
|
||||
filtered
|
||||
inaccessible
|
||||
sampled
|
||||
partially sampled
|
||||
```
|
||||
|
||||
### The membrane defines reusable organism classes
|
||||
|
||||
The same evolved core can be specialized through different membranes:
|
||||
|
||||
```text
|
||||
GenericInformationOrganism
|
||||
│
|
||||
├── CustomerServiceMembrane
|
||||
├── SecurityOperationsMembrane
|
||||
├── FinanceMembrane
|
||||
└── SoftwareEngineeringMembrane
|
||||
```
|
||||
|
||||
### Membranes may themselves be heritable
|
||||
|
||||
Lineages can inherit successful perceptual strategies.
|
||||
|
||||
Mutation can affect:
|
||||
|
||||
```text
|
||||
what is sampled
|
||||
how frequently
|
||||
at what resolution
|
||||
under what conditions
|
||||
```
|
||||
|
||||
### Membrane control becomes organism shaping
|
||||
|
||||
> **To deploy an information organism, first define its membrane, not its intelligence.**
|
||||
|
||||
### Compact formalization
|
||||
|
||||
If the environment at time \(t\) contains potential information \(E_t\), the organism does not receive all of \(E_t\).
|
||||
|
||||
Its membrane computes:
|
||||
|
||||
\[
|
||||
O_t = M(E_t, G_t, R_t, S_t, C)
|
||||
\]
|
||||
|
||||
where:
|
||||
|
||||
- \(G_t\) = active goals,
|
||||
- \(R_t\) = available resources,
|
||||
- \(S_t\) = organism state,
|
||||
- \(C\) = constitutional constraints.
|
||||
|
||||
Likewise:
|
||||
|
||||
\[
|
||||
A'_t = M_{out}(A_t,C,\text{authority})
|
||||
\]
|
||||
|
||||
Only \(A'_t\) reaches the environment.
|
||||
|
||||
### Redrawn concept
|
||||
|
||||
```text
|
||||
ENVIRONMENT
|
||||
|
||||
information consequences
|
||||
│ ▲
|
||||
▼ │
|
||||
╔══════════════════════════════╗
|
||||
║ MEMBRANE ║
|
||||
║ ║
|
||||
║ access ║
|
||||
║ sampling ║
|
||||
║ filtering ║
|
||||
║ projection ║
|
||||
║ attention ║
|
||||
║ governance ║
|
||||
║ actuation ║
|
||||
╚══════════════╤═══════════════╝
|
||||
│
|
||||
▼
|
||||
┌─────────────┐
|
||||
│ ORGANISM │
|
||||
│ │
|
||||
│ memory │
|
||||
│ prediction │
|
||||
│ learning │
|
||||
│ goals │
|
||||
│ planning │
|
||||
└─────────────┘
|
||||
│
|
||||
intention/action
|
||||
│
|
||||
▼
|
||||
MEMBRANE
|
||||
```
|
||||
|
||||
Foundational structural concepts:
|
||||
|
||||
```text
|
||||
Kernel
|
||||
Membrane
|
||||
Genotype
|
||||
Phenotype
|
||||
Environment
|
||||
```
|
||||
|
||||
A stronger definition:
|
||||
|
||||
> **A bounded, resource-constrained, adaptive information-processing system coupled to an environment through a governed membrane. The membrane determines what environmental information becomes experience and which internal intentions may become environmental actions. From sampled experience, externally supplied objectives, feedback, and available resources, the organism develops semantic structures and behaviors that improve its usefulness within that environment. Its developmental configuration may be inherited, mutated, recombined, and selected across generations.**
|
||||
|
||||
And:
|
||||
|
||||
> **The membrane is the governed perceptual and actuation boundary that constructs the organism's effective environment by controlling access, sampling, projection, attention, retention, and action.**
|
||||
|
||||
The more fundamental invention is:
|
||||
|
||||
> **a seedable, governable, evolvable information organism whose intelligence emerges through controlled coupling with an information environment.**
|
||||
580
concepts/MetabolismModel.md
Normal file
580
concepts/MetabolismModel.md
Normal file
|
|
@ -0,0 +1,580 @@
|
|||
<!--
|
||||
Provenance: promoted verbatim from history/20261011-InitialExploration.md
|
||||
(lines 3204–3773, conversation dated 2026-10-06), including the originating
|
||||
question(s). Promoted 2026-10-12 under ASSEMBLY-WP-0002-T06. Consolidation
|
||||
happens in later commits; history/ keeps the original.
|
||||
-->
|
||||
|
||||
# Metabolism Model
|
||||
|
||||
**Status:** Concept v0.1, exploratory. Part of the information-organism lens (INTENT.md, Two Lenses).
|
||||
|
||||
---
|
||||
|
||||
**Originating question:**
|
||||
|
||||
> Good, can we describe what we discuss through the lens of how a metabolism for information organsms looks like. What is the substrate we need? I am thinking information artifacts, compute allowances, runtime environments etc.
|
||||
|
||||
Yes. I think **metabolism** is the right lens because it forces us to distinguish the organism from the material and energy flows that sustain it.
|
||||
|
||||
For an information organism, metabolism is not just “running inference.” It is the complete cycle by which the organism acquires information and resources, transforms them into internal structure and useful action, expends scarce capacity, and disposes of or compresses what is no longer useful.
|
||||
|
||||
> **Information metabolism is the regulated conversion of environmental information, compute, time, storage, authority, and attention into internal models, decisions, actions, and externally useful effects.**
|
||||
|
||||
### 1. The basic metabolic equation
|
||||
|
||||
An information organism consumes:
|
||||
|
||||
```text
|
||||
information artifacts
|
||||
+ compute
|
||||
+ storage
|
||||
+ runtime capacity
|
||||
+ external services
|
||||
+ human attention
|
||||
+ authority
|
||||
+ time
|
||||
```
|
||||
|
||||
and produces:
|
||||
|
||||
```text
|
||||
interpretations
|
||||
predictions
|
||||
decisions
|
||||
actions
|
||||
new information artifacts
|
||||
learned structure
|
||||
coordination
|
||||
environmental change
|
||||
```
|
||||
|
||||
plus waste:
|
||||
|
||||
```text
|
||||
obsolete memory
|
||||
failed hypotheses
|
||||
redundant representations
|
||||
logs
|
||||
temporary embeddings
|
||||
dead branches
|
||||
unused intermediate results
|
||||
compute heat/cost
|
||||
```
|
||||
|
||||
At the highest level:
|
||||
|
||||
```text
|
||||
SUBSTRATE
|
||||
↓
|
||||
METABOLISM
|
||||
↓
|
||||
USEFUL WORK + LEARNED STRUCTURE + WASTE
|
||||
```
|
||||
|
||||
### 2. Substrate vs nutrients
|
||||
|
||||
The **substrate** is what makes metabolism possible.
|
||||
|
||||
The **nutrients** are what the organism consumes during operation.
|
||||
|
||||
**Substrate**
|
||||
|
||||
```text
|
||||
runtime environment
|
||||
storage
|
||||
execution engine
|
||||
network connectivity
|
||||
identity
|
||||
credentials
|
||||
resource accounting
|
||||
semantic membrane
|
||||
```
|
||||
|
||||
**Nutrients**
|
||||
|
||||
```text
|
||||
documents
|
||||
events
|
||||
messages
|
||||
prompts
|
||||
data
|
||||
compute budget
|
||||
API allowance
|
||||
human feedback
|
||||
```
|
||||
|
||||
### 3. Six fundamental substrate layers
|
||||
|
||||
```text
|
||||
1. Information substrate
|
||||
2. Computational substrate
|
||||
3. Memory substrate
|
||||
4. Execution substrate
|
||||
5. Interaction substrate
|
||||
6. Governance substrate
|
||||
```
|
||||
|
||||
### 4. Information substrate
|
||||
|
||||
Raw informational material:
|
||||
|
||||
```text
|
||||
documents
|
||||
database records
|
||||
events
|
||||
messages
|
||||
source code
|
||||
telemetry
|
||||
images
|
||||
schemas
|
||||
contracts
|
||||
policies
|
||||
API responses
|
||||
human statements
|
||||
```
|
||||
|
||||
The membrane converts raw information artifacts into metabolically accessible information.
|
||||
|
||||
### 5. Compute is the energy substrate
|
||||
|
||||
Compute comes in forms such as:
|
||||
|
||||
```text
|
||||
CPU
|
||||
GPU
|
||||
accelerator time
|
||||
LLM tokens
|
||||
database queries
|
||||
network transfer
|
||||
external API calls
|
||||
```
|
||||
|
||||
These can often be translated into a common economic resource:
|
||||
|
||||
```text
|
||||
cost
|
||||
```
|
||||
|
||||
or:
|
||||
|
||||
```text
|
||||
compute credits
|
||||
```
|
||||
|
||||
### 6. Prompts are more like hormones than nutrients
|
||||
|
||||
Prompts modulate processing.
|
||||
|
||||
They alter:
|
||||
|
||||
```text
|
||||
goal activation
|
||||
attention
|
||||
sampling
|
||||
resource allocation
|
||||
```
|
||||
|
||||
So:
|
||||
|
||||
```text
|
||||
Prompt → metabolic direction
|
||||
Budget → metabolic capacity
|
||||
```
|
||||
|
||||
### 7. Runtime is the physical habitat/body substrate
|
||||
|
||||
The organism must exist somewhere:
|
||||
|
||||
```text
|
||||
container
|
||||
VM
|
||||
Kubernetes workload
|
||||
serverless process
|
||||
agent runtime
|
||||
database
|
||||
message broker
|
||||
filesystem
|
||||
network namespace
|
||||
```
|
||||
|
||||
The runtime provides execution, isolation, scheduling, resource limits, connectivity, and persistence.
|
||||
|
||||
### 8. Memory is metabolically expensive tissue
|
||||
|
||||
Retained information has costs:
|
||||
|
||||
```text
|
||||
storage
|
||||
indexing
|
||||
retrieval
|
||||
maintenance
|
||||
security
|
||||
context pollution
|
||||
```
|
||||
|
||||
The organism should decide when to retain, compress, summarize, generalize, forget, or archive.
|
||||
|
||||
### 9. Information digestion
|
||||
|
||||
```text
|
||||
raw artifact
|
||||
↓
|
||||
accessible representation
|
||||
↓
|
||||
decoded content
|
||||
↓
|
||||
semantic claims
|
||||
↓
|
||||
relevant observation
|
||||
↓
|
||||
internal activation
|
||||
```
|
||||
|
||||
This suggests **information digestibility**.
|
||||
|
||||
### 10. Metabolic pathways
|
||||
|
||||
Examples:
|
||||
|
||||
**Retrieval pathway**
|
||||
|
||||
```text
|
||||
question
|
||||
→ identify information need
|
||||
→ query source
|
||||
→ retrieve artifact
|
||||
→ project semantics
|
||||
→ answer
|
||||
```
|
||||
|
||||
**Classification pathway**
|
||||
|
||||
```text
|
||||
incoming artifact
|
||||
→ decode
|
||||
→ extract features
|
||||
→ compare patterns
|
||||
→ classify
|
||||
→ emit event
|
||||
```
|
||||
|
||||
**Planning pathway**
|
||||
|
||||
```text
|
||||
goal
|
||||
→ construct alternatives
|
||||
→ predict consequences
|
||||
→ evaluate
|
||||
→ select
|
||||
```
|
||||
|
||||
**Learning pathway**
|
||||
|
||||
```text
|
||||
episodes
|
||||
→ detect regularity
|
||||
→ form hypothesis
|
||||
→ test
|
||||
→ strengthen structure
|
||||
```
|
||||
|
||||
### 11. Enzymes have a useful computational analogue
|
||||
|
||||
Equivalent computational enzymes:
|
||||
|
||||
```text
|
||||
tools
|
||||
models
|
||||
functions
|
||||
agents
|
||||
parsers
|
||||
indexers
|
||||
retrievers
|
||||
reasoners
|
||||
classifiers
|
||||
```
|
||||
|
||||
A regex is cheap and specialized.
|
||||
|
||||
An LLM is general but expensive.
|
||||
|
||||
A useful organism learns which transformation mechanism is appropriate.
|
||||
|
||||
### 12. Compute allocation becomes metabolic regulation
|
||||
|
||||
A central rule:
|
||||
|
||||
> **Use the least expensive metabolic pathway expected to achieve sufficient confidence and utility.**
|
||||
|
||||
### 13. Resource currencies
|
||||
|
||||
Do not collapse everything into money.
|
||||
|
||||
Important currencies include:
|
||||
|
||||
```text
|
||||
compute
|
||||
latency
|
||||
storage
|
||||
bandwidth
|
||||
human attention
|
||||
external API quota
|
||||
risk budget
|
||||
authority
|
||||
money
|
||||
```
|
||||
|
||||
### 14. Authority is also a metabolic resource
|
||||
|
||||
Being allowed to read, write, approve, send, delete, purchase, or deploy changes what the organism can accomplish.
|
||||
|
||||
### 15. Human attention is premium energy
|
||||
|
||||
Human attention should probably have a much higher shadow price than ordinary compute.
|
||||
|
||||
The organism should learn when to interrupt, ask, escalate, or continue independently.
|
||||
|
||||
### 16. Homeostasis becomes resource regulation
|
||||
|
||||
The organism should maintain variables such as:
|
||||
|
||||
```text
|
||||
compute_remaining
|
||||
memory_pressure
|
||||
queue_depth
|
||||
latency
|
||||
uncertainty
|
||||
human_attention_budget
|
||||
error_rate
|
||||
```
|
||||
|
||||
within useful ranges.
|
||||
|
||||
### 17. Starvation and abundance should change behavior
|
||||
|
||||
Under scarcity:
|
||||
|
||||
```text
|
||||
more reuse
|
||||
more compression
|
||||
less exploration
|
||||
cheaper models
|
||||
more selective sensing
|
||||
```
|
||||
|
||||
Under abundance:
|
||||
|
||||
```text
|
||||
more exploration
|
||||
more simulation
|
||||
deeper evidence retrieval
|
||||
parallel hypotheses
|
||||
structural learning
|
||||
```
|
||||
|
||||
### 18. Metabolic waste
|
||||
|
||||
Waste includes:
|
||||
|
||||
```text
|
||||
temporary scratch data
|
||||
stale embeddings
|
||||
expired caches
|
||||
obsolete hypotheses
|
||||
unused branches
|
||||
duplicate facts
|
||||
low-value logs
|
||||
superseded models
|
||||
```
|
||||
|
||||
Needed processes:
|
||||
|
||||
```text
|
||||
garbage collection
|
||||
forgetting
|
||||
compaction
|
||||
archival
|
||||
deduplication
|
||||
```
|
||||
|
||||
### 19. Excretion is also an interface function
|
||||
|
||||
Some information should leave the organism entirely, such as expired personal data, disallowed retained content, temporary source material, or stale credentials.
|
||||
|
||||
### 20. Growth means conversion of metabolism into structure
|
||||
|
||||
Distinguish:
|
||||
|
||||
```text
|
||||
doing work
|
||||
```
|
||||
|
||||
from:
|
||||
|
||||
```text
|
||||
growing
|
||||
```
|
||||
|
||||
Possible budget split:
|
||||
|
||||
```text
|
||||
maintenance metabolism
|
||||
task metabolism
|
||||
growth metabolism
|
||||
exploration metabolism
|
||||
```
|
||||
|
||||
### 21. A plausible metabolic budget
|
||||
|
||||
```yaml
|
||||
budget:
|
||||
operations: 60%
|
||||
learning: 15%
|
||||
exploration: 10%
|
||||
consolidation: 5%
|
||||
maintenance: 10%
|
||||
```
|
||||
|
||||
### 22. Minimal substrate stack
|
||||
|
||||
```text
|
||||
┌─────────────────────────────────────┐
|
||||
│ Environmental Information Sources │
|
||||
└──────────────────┬──────────────────┘
|
||||
│
|
||||
SEMANTIC MEMBRANE
|
||||
│
|
||||
┌──────────────────▼──────────────────┐
|
||||
│ Information Substrate │
|
||||
│ observations / events / artifacts │
|
||||
├─────────────────────────────────────┤
|
||||
│ Memory Substrate │
|
||||
│ episodes / concepts / models │
|
||||
├─────────────────────────────────────┤
|
||||
│ Computational Substrate │
|
||||
│ CPU / GPU / LLM / tools │
|
||||
├─────────────────────────────────────┤
|
||||
│ Runtime Substrate │
|
||||
│ processes / containers / network │
|
||||
├─────────────────────────────────────┤
|
||||
│ Resource Accounting │
|
||||
│ budgets / quotas / cost │
|
||||
├─────────────────────────────────────┤
|
||||
│ Governance Substrate │
|
||||
│ identity / policy / authority │
|
||||
└─────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 23. Three kinds of substrate availability
|
||||
|
||||
**Ambient substrate**
|
||||
|
||||
```text
|
||||
runtime
|
||||
basic storage
|
||||
network
|
||||
identity
|
||||
```
|
||||
|
||||
**Allocated substrate**
|
||||
|
||||
```text
|
||||
compute budget
|
||||
LLM tokens
|
||||
API quota
|
||||
storage quota
|
||||
```
|
||||
|
||||
**Acquired substrate**
|
||||
|
||||
```text
|
||||
additional compute
|
||||
new data access
|
||||
new tools
|
||||
human attention
|
||||
increased authority
|
||||
```
|
||||
|
||||
### 24. Self-reasoning about metabolism
|
||||
|
||||
The organism can learn:
|
||||
|
||||
```text
|
||||
how expensive am I?
|
||||
which processes waste compute?
|
||||
what knowledge reduces recurring cost?
|
||||
when should I cache?
|
||||
when should I forget?
|
||||
when should I ask for help?
|
||||
```
|
||||
|
||||
### 25. Metabolism ties into evolution
|
||||
|
||||
Different lineages may have different metabolic architectures.
|
||||
|
||||
### 26. A useful hierarchy
|
||||
|
||||
```text
|
||||
SUBSTRATE
|
||||
provides possible resources
|
||||
|
||||
MEMBRANE
|
||||
controls exchange with environment
|
||||
|
||||
METABOLISM
|
||||
converts resources into information work
|
||||
|
||||
ORGANISM
|
||||
maintains identity and learned structure
|
||||
|
||||
ECOSYSTEM
|
||||
allocates resources and selects organisms
|
||||
```
|
||||
|
||||
### 27. Compact metabolic model
|
||||
|
||||
Let the organism receive resources:
|
||||
|
||||
\[
|
||||
R = (I,C,M,A,H,T)
|
||||
\]
|
||||
|
||||
where:
|
||||
|
||||
- \(I\) = information,
|
||||
- \(C\) = compute,
|
||||
- \(M\) = memory/storage,
|
||||
- \(A\) = authority,
|
||||
- \(H\) = human attention,
|
||||
- \(T\) = time.
|
||||
|
||||
The metabolic system performs transformations:
|
||||
|
||||
\[
|
||||
\Phi(R,S,G) \rightarrow (W,S',X)
|
||||
\]
|
||||
|
||||
where:
|
||||
|
||||
- \(S\) = current organism state,
|
||||
- \(G\) = current goals,
|
||||
- \(W\) = useful work returned to the environment,
|
||||
- \(S'\) = changed internal structure,
|
||||
- \(X\) = waste.
|
||||
|
||||
Viability requires, over time:
|
||||
|
||||
\[
|
||||
Value(W + \Delta S) \gtrsim Cost(R)
|
||||
\]
|
||||
|
||||
while staying within governance and safety constraints.
|
||||
|
||||
The substrate should be thought of as the organism's **ecology of consumable capacities**.
|
||||
|
||||
Information artifacts are raw material. Compute is energy. Runtime is habitat/body infrastructure. Memory is tissue. Tools and models are enzymes. Prompts are regulatory signals. Budgets determine metabolic capacity. Human attention is premium metabolic support. Authority determines which transformations can escape into the environment.
|
||||
|
||||
A useful design question for every subsystem is:
|
||||
|
||||
> **What resource enters, what transformation occurs, what useful product emerges, what does it cost, and what waste or persistent structure remains?**
|
||||
431
concepts/NetworkObjectModel.md
Normal file
431
concepts/NetworkObjectModel.md
Normal file
|
|
@ -0,0 +1,431 @@
|
|||
<!--
|
||||
Created 2026-10-12 under ASSEMBLY-WP-0002-T08, as proposed in
|
||||
AdaptiveInformationProcessingNetworkConcept.md § 53.
|
||||
Sources: AdaptiveInformationProcessingNetworkConcept.md §§ 4–18, 21, 34,
|
||||
39–42; MembraneModel.md Part I §§ 8, 9, 11, 17, 18.
|
||||
-->
|
||||
|
||||
# Network Object Model
|
||||
|
||||
**Status:** v0.1, exploratory. Part of the information-organism lens (INTENT.md, Two Lenses).
|
||||
|
||||
## 1. Purpose
|
||||
|
||||
This document turns the entities of the AIPN concept into a precise object
|
||||
model: what objects exist, which fields they carry, how they relate, and which
|
||||
invariants hold between them.
|
||||
|
||||
It stays **implementation-neutral**, as the AIPN concept § 52 requires. It does
|
||||
not choose a storage engine, graph database, programming language, message
|
||||
protocol or numeric representation. Field types are conceptual (`identifier`,
|
||||
`vector`, `time`, `reference`), not machine types.
|
||||
|
||||
Normative keywords (MUST, SHOULD, MAY) carry over from the source concepts.
|
||||
|
||||
---
|
||||
|
||||
## 2. Notation
|
||||
|
||||
```text
|
||||
ObjectName
|
||||
field: ConceptualType meaning
|
||||
field: [ConceptualType] zero or more
|
||||
field?: ConceptualType optional
|
||||
```
|
||||
|
||||
`ref(X)` is a reference to an object of kind X by identity.
|
||||
`vector<D>` is a multi-dimensional value whose dimensions are named in D.
|
||||
|
||||
---
|
||||
|
||||
## 3. Common envelope
|
||||
|
||||
Every object in the network carries the same envelope. It implements the
|
||||
provenance (§ 41), uncertainty (§ 42), governance envelope (Membrane § 9) and
|
||||
historical state (Membrane § 11) requirements once, instead of per object.
|
||||
|
||||
```text
|
||||
Envelope
|
||||
id: identifier stable identity, independent of activation state
|
||||
kind: ObjectKind
|
||||
provenance: [ref(Evidence)] why this object exists or has its current state
|
||||
governance: GovernanceEnvelope
|
||||
valid_time: interval when the represented fact holds in the world
|
||||
record_time: interval when the network believed it (bi-temporal)
|
||||
confidence?: number absent = not assessed, which differs from 0
|
||||
learnable: LearnabilityMode see § 7
|
||||
```
|
||||
|
||||
```text
|
||||
GovernanceEnvelope
|
||||
classification: label e.g. public, internal, confidential
|
||||
tenant?: identifier
|
||||
owner?: identifier
|
||||
purpose: [label] permitted purposes of processing
|
||||
retention?: policy-reference
|
||||
allowed_processing: [label]
|
||||
inherited_from: [ref(Envelope)] derived knowledge inherits restrictions
|
||||
```
|
||||
|
||||
**Invariant E1.** A derived object's `governance` is at least as restrictive
|
||||
as the union of the envelopes it was derived from, unless an `Authority`
|
||||
explicitly relaxed it (§ 7).
|
||||
|
||||
**Invariant E2.** Unknown is representable. A missing `confidence` or a value
|
||||
in the `unknown` state MUST NOT be read as zero or false.
|
||||
|
||||
---
|
||||
|
||||
## 4. Structure objects
|
||||
|
||||
### 4.1 Node
|
||||
|
||||
```text
|
||||
Node : Envelope
|
||||
semantic_kind: NodeKind EntityType | State | Role | Capability | Process |
|
||||
Resource | Context | Goal | Risk | Observer |
|
||||
Policy | Concept | Chunk
|
||||
label: text
|
||||
state: NodeState
|
||||
```
|
||||
|
||||
```text
|
||||
NodeState
|
||||
activation: ActivationState
|
||||
statistics: vector<frequency, recency, ...>
|
||||
predictors: [ref(PredictionModel)]
|
||||
utility_estimates: vector<goal dimensions>
|
||||
```
|
||||
|
||||
### 4.2 Edge
|
||||
|
||||
```text
|
||||
Edge : Envelope
|
||||
source: ref(Node)
|
||||
target: ref(Node)
|
||||
relation: RelationType is-a | part-of | uses | requires | precedes |
|
||||
associated-with | predicts | enables | inhibits |
|
||||
routes-to | observed-by | contributes-to | ...
|
||||
context?: [ref(Context)] A + Context X → B is a different edge from A → B
|
||||
properties: EdgeProperties
|
||||
activation: ActivationState
|
||||
```
|
||||
|
||||
```text
|
||||
EdgeProperties (AIPN § 21: four independent properties)
|
||||
association: number co-occurrence strength
|
||||
prediction: number transition / conditional probability
|
||||
utility: vector<goal dimensions> e.g. correctness, latency, cost
|
||||
confidence: number evidence-weighted trust in the above
|
||||
```
|
||||
|
||||
**Invariant S1.** `association`, `prediction`, `utility` and `confidence` MUST
|
||||
be stored and updated independently. No operation may collapse them into one
|
||||
scalar.
|
||||
|
||||
### 4.3 Chunk
|
||||
|
||||
```text
|
||||
Chunk : Node semantic_kind = Chunk
|
||||
members: [ref(Node | Edge | Chunk)]
|
||||
pattern: PatternDescription sequence, subgraph, recurring context, workflow, ...
|
||||
formation: ref(Episode) episodes that justified formation
|
||||
```
|
||||
|
||||
A Chunk is a Node and can be activated, linked and chunked again (hierarchy).
|
||||
Across lenses, a chunk is an *assembly at organism scale* (Glossary).
|
||||
|
||||
### 4.4 Context
|
||||
|
||||
```text
|
||||
Context : Node semantic_kind = Context
|
||||
condition: ConditionDescription
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. Activity objects
|
||||
|
||||
### 5.1 Token
|
||||
|
||||
```text
|
||||
Token : Envelope
|
||||
source_binding?: ref(SourceBinding) absent for internally generated tokens
|
||||
external_ref?: identifier identity in the system of record
|
||||
persistence: transient | persistent | external | reconstructed
|
||||
activates: [ref(Node)] one token may activate many nodes
|
||||
```
|
||||
|
||||
### 5.2 ActivationState
|
||||
|
||||
Activation is *state*, not an object with its own identity.
|
||||
|
||||
```text
|
||||
ActivationState
|
||||
level: number
|
||||
sources: [ActivationSource] token | neighbor | goal | context | prediction |
|
||||
surprise | attention | regulation | memory
|
||||
decay: DecayRule activation decays unless sustained
|
||||
as_of: time
|
||||
```
|
||||
|
||||
### 5.3 Episode
|
||||
|
||||
```text
|
||||
Episode : Envelope
|
||||
inputs: [ref(Token)]
|
||||
context: [ref(Context)]
|
||||
activations: [ActivationRecord] node or edge, level, time
|
||||
predictions: [ref(Prediction)]
|
||||
actions: [ref(Action)]
|
||||
observations: [ref(Claim)]
|
||||
signals: [ref(Signal)]
|
||||
boundary: interval
|
||||
```
|
||||
|
||||
Episodes are the unit of learning, replay, explanation, attribution and audit.
|
||||
|
||||
### 5.4 Prediction
|
||||
|
||||
```text
|
||||
Prediction : Envelope
|
||||
made_in: ref(Episode)
|
||||
subject: ref(Node | Token | Context)
|
||||
expectation: ExpectationDescription occurrence OR absence
|
||||
horizon: interval
|
||||
resolution?: ref(Claim) the observation that confirmed or refuted it
|
||||
error?: vector<dimensions>
|
||||
```
|
||||
|
||||
### 5.5 Action
|
||||
|
||||
```text
|
||||
Action : Envelope
|
||||
kind: ref(Node) e.g. RouteToHumanReview, Escalate
|
||||
target?: ref(Token | SourceBinding)
|
||||
state: ActionState
|
||||
state_history: [(ActionState, time, ref(Authority)?)]
|
||||
caused_by: ref(Episode)
|
||||
```
|
||||
|
||||
```text
|
||||
ActionState = possible | permitted | recommended | selected | executed | mandatory
|
||||
```
|
||||
|
||||
**Invariant A1.** These states MUST NOT be treated as equivalent. A
|
||||
transition into `permitted` or `mandatory` MUST name an `Authority`; the
|
||||
network may not grant these states to itself.
|
||||
|
||||
**Invariant A2.** "Something happened" (a Claim) and "the network caused
|
||||
something to happen" (an executed Action) are distinct objects.
|
||||
|
||||
### 5.6 EligibilityTrace
|
||||
|
||||
```text
|
||||
EligibilityTrace
|
||||
subject: ref(Node | Edge | Prediction | Action)
|
||||
episode: ref(Episode)
|
||||
strength: number
|
||||
decay: DecayRule
|
||||
```
|
||||
|
||||
Like ActivationState, a trace is temporary state used for delayed credit
|
||||
assignment, not a durable object.
|
||||
|
||||
---
|
||||
|
||||
## 6. Evaluation objects
|
||||
|
||||
### 6.1 Observer
|
||||
|
||||
```text
|
||||
Observer : Node semantic_kind = Observer
|
||||
observes: [ref(Node | Goal | ViabilityVariable)]
|
||||
method: EvaluationDescription
|
||||
operator?: human | artificial | institutional
|
||||
```
|
||||
|
||||
Multiple observers MAY evaluate the same episode differently. Their signals
|
||||
are kept side by side, not averaged at the source.
|
||||
|
||||
### 6.2 Signal
|
||||
|
||||
```text
|
||||
Signal : Envelope
|
||||
emitted_by: ref(Observer)
|
||||
about: ref(Episode)
|
||||
kind: success | failure | reward | penalty | prediction-error | novelty |
|
||||
surprise | constraint-violation | human-feedback | viability-deviation
|
||||
value: vector<dimensions> multi-dimensional by default
|
||||
```
|
||||
|
||||
**Invariant V1.** A signal's `value` MUST stay multi-dimensional through
|
||||
storage. Any aggregation is a separate, explicit step that records its
|
||||
weights.
|
||||
|
||||
### 6.3 Goal
|
||||
|
||||
```text
|
||||
Goal : Node semantic_kind = Goal
|
||||
tendency: GoalDescription desired condition, outcome or constraint
|
||||
source: ref(Authority) goals are received from the environment
|
||||
priority?: number
|
||||
conflicts: [ref(Goal)] conflicts stay visible, never silently flattened
|
||||
```
|
||||
|
||||
### 6.4 ViabilityVariable
|
||||
|
||||
```text
|
||||
ViabilityVariable : Node
|
||||
measure: ref(Node | SourceBinding)
|
||||
corridor: range acceptable operating range
|
||||
floor_kind: corridor | constitutional
|
||||
current: value
|
||||
```
|
||||
|
||||
`constitutional` corridors are non-tradeable floors. They correspond to GADM's
|
||||
constitutional constraints (Glossary, "Viability").
|
||||
|
||||
**Invariant V2.** Viability precedes optimization. No utility gain may justify
|
||||
an action that is predicted to push a `constitutional` variable out of its
|
||||
corridor.
|
||||
|
||||
---
|
||||
|
||||
## 7. Governance objects
|
||||
|
||||
### 7.1 Authority
|
||||
|
||||
```text
|
||||
Authority : Envelope
|
||||
holder: human | institution | delegated-role
|
||||
scope: [label] what it may permit, mandate, relax or make learnable
|
||||
granted_by?: ref(Authority)
|
||||
```
|
||||
|
||||
### 7.2 Learnability
|
||||
|
||||
```text
|
||||
LearnabilityMode = learnable | learnable-with-authority | frozen
|
||||
```
|
||||
|
||||
**Invariant G1.** The learning operation `L` (§ 9) MUST NOT modify an object
|
||||
whose mode is `frozen`. It may modify a `learnable-with-authority` object only
|
||||
when a referenced Authority covers that scope (AIPN § 39: learning and
|
||||
authority are distinct).
|
||||
|
||||
---
|
||||
|
||||
## 8. Membrane objects
|
||||
|
||||
### 8.1 SourceBinding
|
||||
|
||||
```text
|
||||
SourceBinding : Envelope
|
||||
semantic_entity: ref(Node)
|
||||
source_system: identifier
|
||||
source_type: label
|
||||
identity_mapping: MappingDescription
|
||||
projection_rule: ProjectionDescription read model, not a replica
|
||||
access_policy: PolicyReference
|
||||
freshness_policy: PolicyReference
|
||||
write_capabilities: [label] what actions may write back, if anything
|
||||
membrane_layer: constitutional | operational | adaptive | ephemeral
|
||||
```
|
||||
|
||||
### 8.2 Claim
|
||||
|
||||
```text
|
||||
Claim : Envelope
|
||||
subject: ref(Token | Node)
|
||||
predicate: label
|
||||
object: value | ref(Token | Node)
|
||||
source: ref(SourceBinding | Observer)
|
||||
authority?: ref(Authority)
|
||||
observed_time: time
|
||||
```
|
||||
|
||||
Claims allow contradictions: two claims with the same subject and predicate
|
||||
and different objects can coexist without corrupting the model.
|
||||
|
||||
### 8.3 Evidence
|
||||
|
||||
```text
|
||||
Evidence : Envelope
|
||||
supports: [ref(Claim | Node | Edge | Chunk)]
|
||||
origin: ref(SourceBinding | Episode | Observer)
|
||||
locator: identifier pointer into the source; the artefact stays at its source
|
||||
```
|
||||
|
||||
**Invariant M1.** Every semantic assertion entering through the membrane is a
|
||||
Claim backed by Evidence. Learning MUST NOT remove provenance.
|
||||
|
||||
---
|
||||
|
||||
## 9. Operations
|
||||
|
||||
The formal model of AIPN § 34 is \(N=(V,E,T,G,O,H)\). The objects map onto it
|
||||
as follows:
|
||||
|
||||
| Formal | Objects |
|
||||
|---|---|
|
||||
| \(V\) nodes | Node, Chunk, Context, Goal, Observer, ViabilityVariable |
|
||||
| \(E\) edges | Edge (with EdgeProperties) |
|
||||
| \(T\) tokens | Token |
|
||||
| \(G\) goals | Goal, ViabilityVariable |
|
||||
| \(O\) observers | Observer |
|
||||
| \(H\) history | Episode, Prediction, Action, Signal, Claim, Evidence (bi-temporal) |
|
||||
|
||||
The two operations:
|
||||
|
||||
```text
|
||||
evaluate: O(τ, G) → [Signal] observers evaluate an episode against goals
|
||||
learn: L(N, τ, [Signal]) → N' the network changes, subject to G1, M1, S1, V1
|
||||
```
|
||||
|
||||
`learn` covers the four core learning modes (associative, predictive,
|
||||
instrumental, structural) and optionally regulatory learning. Structural
|
||||
learning creates or removes Edges and Chunks. Every structural change produces
|
||||
Evidence that references the Episodes justifying it.
|
||||
|
||||
---
|
||||
|
||||
## 10. Worked example: invoice processing
|
||||
|
||||
```text
|
||||
Token inv-4711 (SourceBinding: SAP AccountingDocument)
|
||||
activates Invoice, SupplierInvoice, HighValueTransaction, Supplier:Acme, MonthEnd
|
||||
Edge Invoice --routes-to--> HumanReview context: [MonthEnd]
|
||||
properties association 0.42, prediction 0.18, utility {correctness .94, latency .31, cost .22}, confidence .91
|
||||
Prediction "approval within 2 days" horizon 2d
|
||||
Action RouteToHumanReview state: recommended → selected → executed
|
||||
permitted by Authority: AP-Policy-2026
|
||||
Claim inv-4711 approved-at 2026-10-03 source: SAP binding
|
||||
Signal Observer:LatencyObserver → {latency: -0.4, correctness: +0.9}
|
||||
learn edge confidence and utility updated; Evidence → episode ep-1182
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 11. Extension points
|
||||
|
||||
The following belong to other organism-lens concepts and are left as named
|
||||
extension points, so this model can grow without reshaping its core:
|
||||
|
||||
| Extension | From | Expected objects |
|
||||
|---|---|---|
|
||||
| Membrane layers and sampling | MembraneModel.md | Membrane, SamplingPolicy, Habituation |
|
||||
| Development | SeedKernel.md | Kernel, DevelopmentalStage |
|
||||
| Evolution | EvolutionModel.md | Genotype, Phenotype, Lineage, FitnessAssessment |
|
||||
| Metabolism | MetabolismModel.md | MetabolicBudget, SubstrateFlow, ResourceAccount |
|
||||
| Resource ontology | ResourceOntology.md | ResourceClass, ConversionFunction, SentientBoundary |
|
||||
|
||||
## 12. Open questions
|
||||
|
||||
1. Should Activation be modeled as an event stream (replayable) or only as
|
||||
current state plus Episode records?
|
||||
2. Is `Context` best treated as a Node kind or as an edge qualifier only?
|
||||
3. What is the minimum bi-temporal guarantee: full valid-time history, or
|
||||
only record-time for audit?
|
||||
4. How should a Signal's dimensions be governed, so that observers stay
|
||||
comparable without forcing a fixed schema?
|
||||
|
|
@ -12,19 +12,22 @@ its own. These are working concepts, not an established body of knowledge.
|
|||
| [GenerativeAssemblySocietyConcept.md](GenerativeAssemblySocietyConcept.md) | v0.1 (promoted verbatim) | `seed/GenerativeAssemblySocietyConcept.md` |
|
||||
| [AdaptiveInformationProcessingNetworkConcept.md](AdaptiveInformationProcessingNetworkConcept.md) | v0.1 (extracted; terminology edited) | lines 857–1739 |
|
||||
| [Glossary.md](Glossary.md) | v0.1 | reconciles the two concept documents (ASSEMBLY-WP-0003-T04) |
|
||||
| MembraneModel.md | planned (ASSEMBLY-WP-0002-T03) | lines 1747–2065 (IT integration), 2882–3203 (membrane as filter) |
|
||||
| SeedKernel.md | planned (ASSEMBLY-WP-0002-T04) | lines 2070–2437 |
|
||||
| EvolutionModel.md | planned (ASSEMBLY-WP-0002-T05) | lines 2442–2877 |
|
||||
| MetabolismModel.md | planned (ASSEMBLY-WP-0002-T06) | lines 3208–3775 |
|
||||
| ResourceOntology.md | planned (ASSEMBLY-WP-0002-T07) | lines 3780–4263 |
|
||||
| NetworkObjectModel.md | planned (ASSEMBLY-WP-0002-T08) | derived from AdaptiveInformationProcessingNetworkConcept.md § 53 |
|
||||
| [MembraneModel.md](MembraneModel.md) | v0.1 (promoted verbatim, two parts) | lines 1747–2065 (IT integration), 2882–3203 (membrane as filter) |
|
||||
| [SeedKernel.md](SeedKernel.md) | v0.1 (promoted verbatim) | lines 2070–2437 |
|
||||
| [EvolutionModel.md](EvolutionModel.md) | v0.1 (promoted verbatim; terminology edited) | lines 2442–2877 |
|
||||
| [MetabolismModel.md](MetabolismModel.md) | v0.1 (promoted verbatim) | lines 3208–3775 |
|
||||
| [ResourceOntology.md](ResourceOntology.md) | v0.1 (promoted verbatim) | lines 3780–4263 |
|
||||
| [NetworkObjectModel.md](NetworkObjectModel.md) | v0.1 (new; ASSEMBLY-WP-0002-T08) | derived from AdaptiveInformationProcessingNetworkConcept.md § 53 |
|
||||
|
||||
## Conventions
|
||||
|
||||
- Every document opens with a provenance comment that names its source lines
|
||||
and the task that created it.
|
||||
- Promotion is verbatim first. Consolidation and edits happen in later commits,
|
||||
so the diff shows every change against the original.
|
||||
- Promotion is verbatim first, including the originating question. Consolidation
|
||||
and edits happen in later commits, so the diff shows every change against the
|
||||
original.
|
||||
- Cross-lens alignments are added as an appendix ("Cross-lens notes") so the
|
||||
promoted body stays intact.
|
||||
- Version is stated in the document header (`v0.1`, `v0.2`, …). Bump it on
|
||||
substantive changes, not on wording fixes.
|
||||
- Implementation-specific material (storage, protocols, APIs) stays out of
|
||||
|
|
|
|||
499
concepts/ResourceOntology.md
Normal file
499
concepts/ResourceOntology.md
Normal file
|
|
@ -0,0 +1,499 @@
|
|||
<!--
|
||||
Provenance: promoted verbatim from history/20261011-InitialExploration.md
|
||||
(lines 3776–4264, conversation dated 2026-10-06), including the originating
|
||||
question(s). Promoted 2026-10-12 under ASSEMBLY-WP-0002-T07. Consolidation
|
||||
happens in later commits; history/ keeps the original.
|
||||
-->
|
||||
|
||||
# Resource Ontology and Attention
|
||||
|
||||
**Status:** Concept v0.1, exploratory. Part of the information-organism lens (INTENT.md, Two Lenses).
|
||||
|
||||
---
|
||||
|
||||
**Originating question:**
|
||||
|
||||
> Good, i like the substrate dimensions and the separation of substrate and nutrients. I especially recognized the phrases "Human attention is premium energy" and "Common economic resource". There is a connection between the idea of nutrition and money/cost but they are on different layers of abstraction. Money is an interesting form of high value energy that can easily be transformed into other forms. In the end it is an end towards other means. And it can not substitute human attention. Another point of view is that human attention is valued in economics and regulating this connection can go a long way to establish a healthy/happy situation for humans as scentient beings in economically efficient societies where several dimensions of human capacity are exceeded by super systems like power machines being more physically capable, computing machines providing superhuman speed calculations and not superintelligence providing superhuman reasoning capabilities.
|
||||
|
||||
Yes. I think this adds an important second layer to the metabolic model: **resource accounting is not the same thing as resource ontology**.
|
||||
|
||||
Money is extraordinarily useful because it acts as a highly fungible claim on many other resources, but it is not itself equivalent to those resources. Human attention makes that distinction especially visible.
|
||||
|
||||
I would frame the system with two layers:
|
||||
|
||||
```text
|
||||
Physical / operational resources
|
||||
↓
|
||||
Economic valuation and exchange
|
||||
```
|
||||
|
||||
At the lower layer we have actual capacities:
|
||||
|
||||
```text
|
||||
compute
|
||||
storage
|
||||
bandwidth
|
||||
electricity
|
||||
machine time
|
||||
human attention
|
||||
human judgment
|
||||
physical labor
|
||||
land
|
||||
materials
|
||||
time
|
||||
authority
|
||||
```
|
||||
|
||||
At the higher layer we have abstract mechanisms for allocating them:
|
||||
|
||||
```text
|
||||
money
|
||||
budgets
|
||||
prices
|
||||
quotas
|
||||
credits
|
||||
contracts
|
||||
markets
|
||||
```
|
||||
|
||||
Money is therefore something like **generalized potential for resource acquisition**.
|
||||
|
||||
It can often be converted into:
|
||||
|
||||
```text
|
||||
€ → compute
|
||||
€ → electricity
|
||||
€ → storage
|
||||
€ → machine capacity
|
||||
€ → external services
|
||||
€ → labor time
|
||||
```
|
||||
|
||||
but the conversion is neither perfect nor universal.
|
||||
|
||||
And this is where human attention becomes especially interesting.
|
||||
|
||||
### Human attention is not merely another commodity
|
||||
|
||||
Economically, attention has a price. But ontologically, it is very different from GPU time.
|
||||
|
||||
A person has only:
|
||||
|
||||
```text
|
||||
24 hours/day
|
||||
limited waking time
|
||||
limited sustained concentration
|
||||
limited emotional capacity
|
||||
limited cognitive switching capacity
|
||||
```
|
||||
|
||||
Money can persuade someone to allocate some of this capacity differently.
|
||||
|
||||
It cannot manufacture an additional hour of that person's conscious life.
|
||||
|
||||
So I would distinguish between **fungible** and **non-fungible metabolic resources**.
|
||||
|
||||
| Resource | Replaceable? | Expandable? | Monetizable? |
|
||||
|---|---:|---:|---:|
|
||||
| Compute | highly | highly | highly |
|
||||
| Storage | highly | highly | highly |
|
||||
| Electricity | highly | moderately | highly |
|
||||
| Machine labor | highly | highly | highly |
|
||||
| Human labor | partially | partially | highly |
|
||||
| Human attention | weakly | very weakly | partially |
|
||||
| Trust | weakly | slowly | poorly |
|
||||
| Expertise | partially | slowly | partially |
|
||||
| Human lifetime | no | no | imperfectly |
|
||||
|
||||
This distinction should probably matter to the information-organism model.
|
||||
|
||||
### Money as high-grade potential energy
|
||||
|
||||
Money resembles a **portable potential-energy representation** because it preserves optionality.
|
||||
|
||||
A fixed GPU-hour can do only certain things.
|
||||
|
||||
€100 can potentially become:
|
||||
|
||||
```text
|
||||
GPU time
|
||||
human consulting
|
||||
electricity
|
||||
storage
|
||||
data access
|
||||
transport
|
||||
equipment
|
||||
```
|
||||
|
||||
So money has high **resource optionality**.
|
||||
|
||||
That suggests a distinction between:
|
||||
|
||||
```text
|
||||
specific resource
|
||||
versus
|
||||
generalized resource potential
|
||||
```
|
||||
|
||||
Money belongs primarily to the latter.
|
||||
|
||||
A useful formulation might be:
|
||||
|
||||
> **Money is a highly fungible coordination token representing socially recognized claims on future resources and capacities.**
|
||||
|
||||
That is why budgets are such an elegant way of constraining information organisms: they do not dictate exactly *how* resources must be consumed.
|
||||
|
||||
They establish a metabolic envelope within which the organism can decide:
|
||||
|
||||
```text
|
||||
Should I buy more compute?
|
||||
Should I call an API?
|
||||
Should I ask a human?
|
||||
Should I wait?
|
||||
Should I reuse stored knowledge?
|
||||
```
|
||||
|
||||
### Resource exchange needs conversion functions
|
||||
|
||||
We should not model:
|
||||
|
||||
\[
|
||||
€1 = X \text{ compute}
|
||||
\]
|
||||
|
||||
as a universal constant.
|
||||
|
||||
Instead:
|
||||
|
||||
\[
|
||||
r_i \xrightarrow{market/context} r_j
|
||||
\]
|
||||
|
||||
For example, money → compute may be cheap and predictable, while money → expert human attention depends on availability, willingness, relationship, urgency, expertise, time of day, and social norms.
|
||||
|
||||
Money → trust may not be directly possible at all.
|
||||
|
||||
So the resource model requires **convertibility**, not merely price.
|
||||
|
||||
### Hierarchy of resource classes
|
||||
|
||||
#### Commodity resources
|
||||
|
||||
```text
|
||||
CPU
|
||||
GPU
|
||||
storage
|
||||
bandwidth
|
||||
electricity
|
||||
```
|
||||
|
||||
#### Capability resources
|
||||
|
||||
```text
|
||||
specific model
|
||||
specialized tool
|
||||
expertise
|
||||
machine capability
|
||||
```
|
||||
|
||||
#### Human resources
|
||||
|
||||
```text
|
||||
attention
|
||||
judgment
|
||||
creativity
|
||||
care
|
||||
responsibility
|
||||
presence
|
||||
```
|
||||
|
||||
#### Institutional resources
|
||||
|
||||
```text
|
||||
money
|
||||
authority
|
||||
trust
|
||||
legal rights
|
||||
reputation
|
||||
access
|
||||
```
|
||||
|
||||
These interact, but should not be collapsed.
|
||||
|
||||
### Human attention deserves special treatment
|
||||
|
||||
> Human attention is a scarce, non-renewable-at-the-individual-timescale, semantically rich resource whose expenditure consumes part of a sentient being's finite lived experience.
|
||||
|
||||
If a system uses 10 additional GPU-hours, the cost is primarily economic/environmental.
|
||||
|
||||
If it unnecessarily consumes 2 hours of a person's concentrated attention, it has consumed two hours of that person's life.
|
||||
|
||||
Money can compensate the person economically, but it does not restore those two hours.
|
||||
|
||||
### Superhuman systems change the comparative advantage landscape
|
||||
|
||||
A useful sequence:
|
||||
|
||||
```text
|
||||
mechanical machines
|
||||
→ superhuman physical power
|
||||
|
||||
computers
|
||||
→ superhuman arithmetic / speed
|
||||
|
||||
AI systems
|
||||
→ increasingly superhuman information processing and reasoning
|
||||
```
|
||||
|
||||
If artificial systems exceed humans across broad cognitive dimensions, then a society organized purely around:
|
||||
|
||||
> economic value = productive superiority
|
||||
|
||||
becomes unstable from the standpoint of human welfare.
|
||||
|
||||
This does not imply that humans become economically valueless.
|
||||
|
||||
It means the **relationship between economic value and human worth has to become more explicit**.
|
||||
|
||||
### Attention regulation may become a core societal control loop
|
||||
|
||||
An economically efficient artificial system might minimize compute cost, storage cost, and latency while externalizing interruptions, human review, decision fatigue, context switching, and emotional burden.
|
||||
|
||||
A healthier architecture treats human attention explicitly as expensive and protected.
|
||||
|
||||
For example:
|
||||
|
||||
\[
|
||||
Cost(action)=
|
||||
C_{compute}
|
||||
+
|
||||
C_{money}
|
||||
+
|
||||
\lambda_h C_{human-attention}
|
||||
\]
|
||||
|
||||
with \(\lambda_h\) deliberately high.
|
||||
|
||||
Then information organisms learn:
|
||||
|
||||
```text
|
||||
don't ask a human
|
||||
unless the expected value of asking
|
||||
exceeds the cost of consuming their attention
|
||||
```
|
||||
|
||||
### Go further than pricing attention
|
||||
|
||||
Price alone is insufficient.
|
||||
|
||||
Human-attention governance needs:
|
||||
|
||||
```text
|
||||
economic valuation
|
||||
+
|
||||
protective constraints
|
||||
```
|
||||
|
||||
Human welfare variables should form viability constraints around economic optimization.
|
||||
|
||||
Possible variables:
|
||||
|
||||
```text
|
||||
income
|
||||
autonomy
|
||||
attention load
|
||||
rest
|
||||
social connectedness
|
||||
health
|
||||
learning opportunity
|
||||
meaningful agency
|
||||
```
|
||||
|
||||
### A powerful role for superintelligence
|
||||
|
||||
Instead of asking:
|
||||
|
||||
> How do humans compete economically against systems that outperform them?
|
||||
|
||||
ask:
|
||||
|
||||
> How do we use superhuman systems to minimize the amount of involuntary human capacity required to maintain society?
|
||||
|
||||
The goal becomes:
|
||||
|
||||
```text
|
||||
maximize:
|
||||
human agency
|
||||
useful abundance
|
||||
discretionary attention
|
||||
safety
|
||||
opportunity
|
||||
|
||||
minimize:
|
||||
compulsory cognitive labor
|
||||
bureaucratic friction
|
||||
dangerous physical labor
|
||||
meaningless repetition
|
||||
involuntary attention capture
|
||||
```
|
||||
|
||||
This reframes automation from:
|
||||
|
||||
```text
|
||||
replace human labor
|
||||
```
|
||||
|
||||
to:
|
||||
|
||||
```text
|
||||
release human capacity
|
||||
```
|
||||
|
||||
### Human attention could become the reference scarce resource
|
||||
|
||||
In a world of abundant machine intelligence, **human conscious attention may become one of the least expandable resources in the system**.
|
||||
|
||||
You cannot horizontally scale a person.
|
||||
|
||||
You can horizontally scale inference.
|
||||
|
||||
This suggests:
|
||||
|
||||
> **Compute should be spent to conserve human attention, not the other way around.**
|
||||
|
||||
### This also changes the meaning of efficiency
|
||||
|
||||
Conventional efficiency:
|
||||
|
||||
\[
|
||||
Efficiency =
|
||||
\frac{output}{money}
|
||||
\]
|
||||
|
||||
A better measure may become:
|
||||
|
||||
\[
|
||||
Efficiency =
|
||||
\frac{useful outcomes}{
|
||||
compute +
|
||||
material resources +
|
||||
environmental cost +
|
||||
human attention
|
||||
}
|
||||
\]
|
||||
|
||||
with human attention separately visible rather than merely converted into euros.
|
||||
|
||||
Even stronger:
|
||||
|
||||
\[
|
||||
Human\ Attention\ Return =
|
||||
\frac{
|
||||
human benefit + human capability released
|
||||
}{
|
||||
human attention consumed
|
||||
}
|
||||
\]
|
||||
|
||||
### Sentience introduces a categorical boundary
|
||||
|
||||
Our information organisms may be called “organisms” structurally without implying sentience.
|
||||
|
||||
If humans remain sentient actors while information organisms are non-sentient machinery, then:
|
||||
|
||||
```text
|
||||
machine compute
|
||||
instrumental resource
|
||||
|
||||
human attention
|
||||
resource economically
|
||||
+
|
||||
lived experience intrinsically
|
||||
```
|
||||
|
||||
That second property prevents full fungibility.
|
||||
|
||||
### A resource ontology could therefore have two axes
|
||||
|
||||
One axis:
|
||||
|
||||
```text
|
||||
fungibility
|
||||
```
|
||||
|
||||
from highly exchangeable to non-substitutable.
|
||||
|
||||
Another:
|
||||
|
||||
```text
|
||||
moral standing of the resource bearer
|
||||
```
|
||||
|
||||
from instrumental substrate to sentient capacity.
|
||||
|
||||
Examples:
|
||||
|
||||
```text
|
||||
GPU compute
|
||||
high fungibility
|
||||
instrumental
|
||||
|
||||
human attention
|
||||
low fungibility
|
||||
sentient-associated
|
||||
|
||||
money
|
||||
very high fungibility
|
||||
institutional abstraction
|
||||
```
|
||||
|
||||
### Resulting societal control loop
|
||||
|
||||
```text
|
||||
HUMAN PURPOSE
|
||||
│
|
||||
▼
|
||||
objectives
|
||||
│
|
||||
▼
|
||||
economic allocation
|
||||
│
|
||||
┌───────────────┼───────────────┐
|
||||
▼ ▼ ▼
|
||||
money compute machine capacity
|
||||
│ │ │
|
||||
└───────────────┼───────────────┘
|
||||
▼
|
||||
information organisms
|
||||
│
|
||||
work
|
||||
│
|
||||
▼
|
||||
abundance
|
||||
│
|
||||
▼
|
||||
human benefit
|
||||
│
|
||||
└──── feedback
|
||||
|
||||
while:
|
||||
|
||||
human attention
|
||||
human autonomy
|
||||
human wellbeing
|
||||
│
|
||||
▼
|
||||
protected viability boundaries
|
||||
```
|
||||
|
||||
A phrase worth keeping:
|
||||
|
||||
> **Money is generalized resource potential; attention is lived capacity.**
|
||||
|
||||
The former can frequently be transformed.
|
||||
|
||||
The latter can only be allocated once.
|
||||
|
||||
And for information-organism design:
|
||||
|
||||
> **Spend abundant machine resources to preserve scarce sentient resources.**
|
||||
380
concepts/SeedKernel.md
Normal file
380
concepts/SeedKernel.md
Normal file
|
|
@ -0,0 +1,380 @@
|
|||
<!--
|
||||
Provenance: promoted verbatim from history/20261011-InitialExploration.md
|
||||
(lines 2066–2435, conversation dated 2026-10-06), including the originating
|
||||
question(s). Promoted 2026-10-12 under ASSEMBLY-WP-0002-T04. Consolidation
|
||||
happens in later commits; history/ keeps the original.
|
||||
-->
|
||||
|
||||
# Seed Kernel
|
||||
|
||||
**Status:** Concept v0.1, exploratory. Part of the information-organism lens (INTENT.md, Two Lenses).
|
||||
|
||||
---
|
||||
|
||||
**Originating question:**
|
||||
|
||||
> Good, this is a very reasonable take. Let me add another idea about the optimal inner kernel of the concept. I would like to think about this in a way of how to establish a minimal kernel that can be connected to an environment and then unfoldes and establishes itself by adapting to the environment. This is like a baby or seed that can be planted in an information environment growing into something like an organizm that is helpful for its environment which shows as the environment feeds the system by providing objectives and resources to reach them. In my mind this translates to prompts and budget for compute.
|
||||
|
||||
Yes. This changes the framing in a useful way: the kernel should not be a miniature finished intelligence system. It should be a **developmental substrate** capable of attaching to an information environment, discovering regularities, acquiring structure, and becoming useful under externally supplied goals and resource constraints.
|
||||
|
||||
The closest metaphor is less “brain” and more **seed + metabolism + development**.
|
||||
|
||||
A compact formulation:
|
||||
|
||||
> **A minimal adaptive kernel starts with almost no domain structure. It is given access to an environment, objectives, and bounded resources. Through observation, interaction, prediction, feedback, and compression, it develops a semantic model and increasingly effective behaviors specific to that environment.**
|
||||
|
||||
### What must exist at birth?
|
||||
|
||||
#### 1. Boundary
|
||||
|
||||
It must distinguish self from environment operationally.
|
||||
|
||||
#### 2. Observation
|
||||
|
||||
It needs a generic way to receive information:
|
||||
|
||||
```text
|
||||
observe(environment) → evidence
|
||||
```
|
||||
|
||||
The semantic membrane becomes its sensory apparatus.
|
||||
|
||||
#### 3. Memory
|
||||
|
||||
The seed needs to retain what happened, when, under which conditions, what it did, and what followed.
|
||||
|
||||
#### 4. Prediction
|
||||
|
||||
It must be able to predict what happens next.
|
||||
|
||||
Prediction followed by observation yields a learning signal.
|
||||
|
||||
#### 5. Action
|
||||
|
||||
It needs bounded ability to affect its environment.
|
||||
|
||||
Initially this might be ask, retrieve, classify, or recommend.
|
||||
|
||||
#### 6. Objective reception
|
||||
|
||||
The environment must be able to tell the seed what matters.
|
||||
|
||||
This maps naturally to **prompts**.
|
||||
|
||||
A prompt becomes a temporary or persistent **goal activation**.
|
||||
|
||||
#### 7. Resource reception
|
||||
|
||||
The second thing supplied by the environment is energy.
|
||||
|
||||
For the information organism:
|
||||
|
||||
```text
|
||||
compute
|
||||
tokens
|
||||
storage
|
||||
API calls
|
||||
human attention
|
||||
time
|
||||
money
|
||||
```
|
||||
|
||||
So **budget is the metabolic resource of the organism**.
|
||||
|
||||
### A minimal kernel
|
||||
|
||||
```text
|
||||
K = {
|
||||
Boundary,
|
||||
Observation,
|
||||
Memory,
|
||||
Prediction,
|
||||
Goal,
|
||||
Resource,
|
||||
Action,
|
||||
Learning
|
||||
}
|
||||
```
|
||||
|
||||
Possibly with `Identity` as a ninth primitive.
|
||||
|
||||
Everything else could be allowed to emerge.
|
||||
|
||||
### Prompts as nutrients? Not quite
|
||||
|
||||
Distinguish:
|
||||
|
||||
```text
|
||||
direction
|
||||
resources
|
||||
```
|
||||
|
||||
Prompts provide direction.
|
||||
|
||||
Compute budget provides metabolic capacity.
|
||||
|
||||
```text
|
||||
Prompt → purpose / objective / constraint
|
||||
Budget → ability to investigate and act
|
||||
```
|
||||
|
||||
The environment effectively says:
|
||||
|
||||
> This matters to me, and I am willing to spend this much energy for you to pursue it.
|
||||
|
||||
### Utility becomes endogenous
|
||||
|
||||
Utility is partly revealed by what the environment repeatedly spends scarce resources on.
|
||||
|
||||
Repeated objective + repeated budget + rewarded outcomes becomes a strong developmental signal.
|
||||
|
||||
### Attention becomes resource allocation
|
||||
|
||||
```text
|
||||
activation
|
||||
↓
|
||||
attention allocation
|
||||
↓
|
||||
compute expenditure
|
||||
```
|
||||
|
||||
Attention is the decision to spend scarce information-processing resources on something.
|
||||
|
||||
### A metabolic loop
|
||||
|
||||
```text
|
||||
ENVIRONMENT
|
||||
│
|
||||
objective + resources
|
||||
│
|
||||
▼
|
||||
perceive
|
||||
↓
|
||||
understand
|
||||
↓
|
||||
predict
|
||||
↓
|
||||
allocate resources
|
||||
↓
|
||||
act
|
||||
↓
|
||||
ENVIRONMENT
|
||||
↓
|
||||
outcome
|
||||
↓
|
||||
evaluate
|
||||
↓
|
||||
learn
|
||||
↓
|
||||
structure changes
|
||||
```
|
||||
|
||||
There is also a second loop:
|
||||
|
||||
```text
|
||||
resources received
|
||||
↓
|
||||
resources spent
|
||||
↓
|
||||
usefulness demonstrated
|
||||
↓
|
||||
environment allocates more resources
|
||||
```
|
||||
|
||||
### The environment should not have to fully specify goals
|
||||
|
||||
Explicit goals may be complemented by implicit reinforcement such as acceptance, ignoring, follow-up, correction, additional budget, and wider access.
|
||||
|
||||
Still:
|
||||
|
||||
```text
|
||||
learned desirability ≠ authority
|
||||
```
|
||||
|
||||
### Development rather than training
|
||||
|
||||
Development means gradually learning what entities exist, which distinctions matter, what actions are possible, what consequences follow, and which abstractions are useful.
|
||||
|
||||
### Innate mechanisms versus acquired structure
|
||||
|
||||
The seed should have a small **genotype**, while the deployed system develops a large **phenotype**.
|
||||
|
||||
```text
|
||||
GENOTYPE
|
||||
observe
|
||||
remember
|
||||
predict
|
||||
compare
|
||||
allocate
|
||||
act
|
||||
learn
|
||||
compress
|
||||
|
||||
↓ development
|
||||
|
||||
PHENOTYPE
|
||||
Invoice
|
||||
Supplier
|
||||
Employee
|
||||
Department
|
||||
PaymentRisk
|
||||
CustomerChurn
|
||||
...
|
||||
```
|
||||
|
||||
### Semantic concepts could emerge from compression
|
||||
|
||||
A seed placed into a company may discover recurring patterns before learning their labels.
|
||||
|
||||
### The seed needs curiosity
|
||||
|
||||
Bounded uncertainty reduction can justify exploration.
|
||||
|
||||
Introduce an **epistemic budget**.
|
||||
|
||||
Possible budget categories:
|
||||
|
||||
```text
|
||||
goal budget
|
||||
maintenance budget
|
||||
exploration budget
|
||||
```
|
||||
|
||||
### Metabolism should include return on compute
|
||||
|
||||
Every expensive processing activity should eventually justify its resource use.
|
||||
|
||||
The system can learn the economics of its own cognition.
|
||||
|
||||
### Two fundamental regulators
|
||||
|
||||
**Epistemic regulation**
|
||||
|
||||
> How wrong / uncertain am I?
|
||||
|
||||
**Resource regulation**
|
||||
|
||||
> How much can I afford?
|
||||
|
||||
Combined with:
|
||||
|
||||
> What matters?
|
||||
|
||||
This gives a triad:
|
||||
|
||||
```text
|
||||
Purpose
|
||||
Knowledge
|
||||
Energy
|
||||
```
|
||||
|
||||
or:
|
||||
|
||||
```text
|
||||
Goals
|
||||
Model
|
||||
Budget
|
||||
```
|
||||
|
||||
### Lifecycle
|
||||
|
||||
```text
|
||||
1. Attach
|
||||
2. Observe
|
||||
3. Orient
|
||||
4. Assist
|
||||
5. Specialize
|
||||
6. Act
|
||||
7. Regulate
|
||||
8. Reflect
|
||||
```
|
||||
|
||||
### Symbiosis may be a better target than autonomy
|
||||
|
||||
Success is a mutually beneficial coupling with the environment.
|
||||
|
||||
The organization provides:
|
||||
|
||||
```text
|
||||
information
|
||||
goals
|
||||
compute
|
||||
authority
|
||||
feedback
|
||||
```
|
||||
|
||||
The organism returns:
|
||||
|
||||
```text
|
||||
predictions
|
||||
coordination
|
||||
reduced effort
|
||||
better decisions
|
||||
adaptation
|
||||
```
|
||||
|
||||
Autonomy is earned through demonstrated viability and usefulness rather than designed in from the beginning.
|
||||
|
||||
### Revised kernel distinction
|
||||
|
||||
**Seed Kernel**
|
||||
|
||||
```text
|
||||
Identity / Boundary
|
||||
Observation
|
||||
Action
|
||||
Memory
|
||||
Prediction
|
||||
GoalInput
|
||||
ResourceBudget
|
||||
Learning
|
||||
```
|
||||
|
||||
**Developed Semantic Network**
|
||||
|
||||
```text
|
||||
Node
|
||||
Edge
|
||||
Concept
|
||||
Context
|
||||
Observer
|
||||
Goal
|
||||
ViabilityVariable
|
||||
Chunk
|
||||
Process
|
||||
Capability
|
||||
Role
|
||||
...
|
||||
```
|
||||
|
||||
A tentative seed formulation:
|
||||
|
||||
\[
|
||||
K=(B,O,M,P,A,G,R,L)
|
||||
\]
|
||||
|
||||
The environment provides:
|
||||
|
||||
\[
|
||||
E=(I,G,R,F)
|
||||
\]
|
||||
|
||||
Development:
|
||||
|
||||
\[
|
||||
(K_t,E_t)\rightarrow K_{t+1}
|
||||
\]
|
||||
|
||||
And a viability condition:
|
||||
|
||||
\[
|
||||
\text{value returned to environment}
|
||||
>
|
||||
\text{resources consumed}
|
||||
\]
|
||||
|
||||
over an appropriate time horizon.
|
||||
|
||||
The stronger center is:
|
||||
|
||||
> **not an adaptive semantic graph that we build, but a bounded information organism that develops a semantic graph as its learned internal structure.**
|
||||
|
|
@ -4,7 +4,7 @@ type: workplan
|
|||
title: "Promote exploration concepts into concepts/"
|
||||
domain: communication
|
||||
repo: assembly-economics
|
||||
status: active
|
||||
status: finished
|
||||
flavor: planning
|
||||
depends_on: []
|
||||
owner: claude-code
|
||||
|
|
@ -49,7 +49,7 @@ ranges in the history file, and the promotion and versioning conventions.
|
|||
|
||||
```task
|
||||
id: ASSEMBLY-WP-0002-T03
|
||||
status: todo
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "17d0fcac-439c-5091-8936-c3f2da8959c7"
|
||||
```
|
||||
|
|
@ -63,7 +63,7 @@ operational, adaptive, ephemeral), and negative space.
|
|||
|
||||
```task
|
||||
id: ASSEMBLY-WP-0002-T04
|
||||
status: todo
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "d76809b7-6a6c-52ac-842b-91d982798560"
|
||||
```
|
||||
|
|
@ -75,7 +75,7 @@ innate vs. acquired structure, lifecycle, symbiosis) into `concepts/SeedKernel.m
|
|||
|
||||
```task
|
||||
id: ASSEMBLY-WP-0002-T05
|
||||
status: todo
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "2ffe2f19-e5a9-5fb4-a40f-9c9403e53a62"
|
||||
```
|
||||
|
|
@ -88,7 +88,7 @@ multi-dimensional fitness, and the constraints kept outside evolution into
|
|||
|
||||
```task
|
||||
id: ASSEMBLY-WP-0002-T06
|
||||
status: todo
|
||||
status: done
|
||||
priority: medium
|
||||
state_hub_task_id: "8b2a4b48-cd08-5586-9bf7-9a169fe75f09"
|
||||
```
|
||||
|
|
@ -101,7 +101,7 @@ pathways, waste, and the compact metabolic model into
|
|||
|
||||
```task
|
||||
id: ASSEMBLY-WP-0002-T07
|
||||
status: todo
|
||||
status: done
|
||||
priority: high
|
||||
state_hub_task_id: "e6fbeef5-c13c-5bc6-9512-084f2eb0eb86"
|
||||
```
|
||||
|
|
@ -114,7 +114,7 @@ functions, the sentient boundary, and the societal attention control loop into
|
|||
|
||||
```task
|
||||
id: ASSEMBLY-WP-0002-T08
|
||||
status: todo
|
||||
status: done
|
||||
priority: low
|
||||
state_hub_task_id: "ec8b650f-5109-5f40-8919-9703b444a4d9"
|
||||
```
|
||||
|
|
@ -126,7 +126,7 @@ model, `concepts/NetworkObjectModel.md`, as AdaptiveInformationProcessingNetwork
|
|||
|
||||
```task
|
||||
id: ASSEMBLY-WP-0002-T09
|
||||
status: todo
|
||||
status: done
|
||||
priority: low
|
||||
state_hub_task_id: "a2a2e121-d6a4-59a7-93d7-c5b6a5883502"
|
||||
```
|
||||
|
|
@ -135,3 +135,14 @@ When the concept documents are next revised, apply the recommendations in
|
|||
`concepts/Glossary.md`. For example: state that chunks are assemblies at
|
||||
organism scale, reserve "agency" for humans, and name membrane control as a
|
||||
domination channel in the society concept.
|
||||
|
||||
## Outcome
|
||||
|
||||
All tasks are done. `concepts/` now holds the full information-organism lens:
|
||||
the AIPN concept, membrane, seed kernel, evolution, metabolism, resource
|
||||
ontology, the Network Object Model, and the glossary, with cross-lens notes.
|
||||
|
||||
Left for later (not started): consolidating the verbatim promotions, which
|
||||
still read as conversation turns, into structured concept documents. This is
|
||||
best done per document, when a modeling or research task needs it.
|
||||
ASSEMBLY-WP-0004 is unblocked by this workplan.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue