Holland bucket-brigade credit assignment
Algorithms AIMech:HollandBucketBrigade DRAFT
A classifier-system credit-assignment procedure in which satisfied condition/action rules compete using strength-and-specificity bids, winning rules pay the suppliers of their triggering messages, and consumer payments together with external payoff adapt strengths along chains of rule activation.
Identity Notes & Concept Scope
This record selects Holland 1985 classifier-system strength bidding and message-supplier credit assignment. It does not equate the entire classifier-system architecture, temporal TD credit, later simplified Sarsa relations or all bucket-brigade variants. The source supplier-display conflict and execution-order gaps remain explicit. Existing owner 268 is reused; its historical Sutton pointer is discovery context, not the selected primary. Fresh collection on 15 October 2026 at 15:21:24–15:22:28 UTC used actual merged base 342606efadd8c2896facca6e6fa2f78e216f0a8b and compared all 766 native and 442 pinned AIO records (4,816 identity-field occurrences including local IDs; 3,680 normalized values). No canonical or explicit Greek-lambda candidate collision was found; 18 context-only fields span eight neighboring records. Four ignored- and hidden-inclusive checkout searches retained 1,353/1,360/3,385/4,292 occurrences, 10,390 total, in 557 exact contents. Root read all 41 candidate-specific decoded semantic contents, all 18 contextual identity fields/eight definitions and nine full relevant frontier objects; repeated identical HTML wrapper text was not counted as a separate scientific reading. Supporting source-agent assessment read all 445 decoded contexts and reconstructed all raw groups/ordered occurrences. All909main and393nested objects were queried mechanically. Historical source/AIO readings retain their separately documented scopes. These results are bounded to the dated corpus, four roots and semantic neighborhood, not global absence or saturation.
Claims & Grounded Evidence
5 Claims
Mechanism
#rule-strength-credit-assignment
In the inspected classifier-system formulation, condition/action rules communicate by posting messages, and each rule has a numerical strength representing its usefulness in the contexts where it acts. The bucket-brigade procedure modifies these strengths to allocate credit to rules that provide conditions for later useful activity. It is the credit-assignment mechanism within the rule system, not the whole classifier-system framework.
Mechanism
#specificity-and-strength-bidding
Rules whose conditions are satisfied compete for activation. In the stated classifier-system version, rule C bids b(C,t)=c*r(C)*s(C,t), where s is its strength and r is the number of specified condition positions, computed as total defining positions minus don’t-care positions. Selected highest bidders become active and post their action messages. Both strength and specificity enter the bid; greater specificity alone does not determine the winning rule.
Mechanism
#winner-debit-and-supplier-credit
A winning rule pays its bid from its strength, giving the displayed debit s(C,t+1)=s(C,t)-b(C,t). In the simplest formulation, that bid is divided equally among the classifiers whose messages satisfy the winner’s conditions: a supplier C1 receives the additive credit b(C,t)/n(C,t), where n counts the supplying classifiers. This states the payment prose and the additive first equality of the supplier display; its inconsistent final expression is retained as a source limitation.
Mechanism
#consumer-payments-and-external-payoff
After a winning rule posts a message, it can become a supplier to rules activated on the next step and receive shares of their bids. When the environment provides payoff, all classifiers active on that step receive equal fractions of it, in addition to payments from their next-step consumers. Credit therefore passes through local message-supplying transactions and externally rewarded activity.
Mechanism
#persistent-rule-bridge
The source illustrates a bridge across a longer sequence using an epoch-marking rule that remains active through the sequence and is active when payoff arrives. If an initiating rule supplies a message that activates this persistent rule, the latter’s increased strength can increase the payment to that initiator on a subsequent use. This construction depends on the persistent rule and the stated supplier coupling; it does not itself discover the required rules.
⚠️ Curated Limitations & Negative Results
- The supplier-strength display on p. 2 ends with (1-c*r(C)/n(C,t))*s(C,t), which is generally inconsistent with its preceding additive expression s(C1,t)+b(C,t)/n(C,t) and the supplier-payment prose. The additive statement is used here and the conflicting printed expression is preserved explicitly. No official erratum, silently repaired full specification or author-implementation behavior is asserted.
- Specificity is a raw count, and describing c as small does not ensure c*r(C)<=1. For the isolated debit, nonnegative strength is preserved under nonnegative starting strength and 0<=c*r(C)<=1; adding nonnegative payments preserves that elementary boundary. These are explicit algebraic conditions, not a source-wide invariant for arbitrary specificity, signed rewards or simultaneous transactions. The equal-share formula also requires n(C,t)>0; the selected description does not resolve every zero-supplier case.
- The article describes the mechanism rather than complete executable pseudocode. It does not fully specify winner cardinality, ties, initial strengths, exploration, no-supplier behavior, overlapping or self-supplier transactions, or a complete order for concurrent debits and credits. These choices cannot be reconstructed as one mandatory implementation from the stated local equations.
- Credit recipients are message suppliers whose outputs satisfy a consumer’s conditions. This is not automatically credit to every temporally preceding rule, a generic eligibility trace, or proof that every paid supplier was counterfactually necessary for the environmental outcome. Restricted temporal-difference analogies do not identify the whole rule-credit procedure with TD, Q-learning or Sarsa.
- The parasite and default/exception hierarchy discussions are conditional illustrations, not general convergence, monotone-improvement or extinction theorems. A more specific exception can still bid less than a stronger default because the bid depends on both factors. The source leaves simultaneous parasite and useful stage-setting activity outside its simple illustration.
- The bridge example requires suitable persistent activation, a message link from the initiator, later payoff and subsequent reuse. It does not guarantee one-shot learning for arbitrary rule sets, immediate propagation to every earlier rule, or automatic discovery of the bridge. Genetic rule discovery and construction of further hierarchy components are additional mechanisms.
- The declared evidence is the inspected seven-page 1985 chapter. The historical discovery source cites a 1986 Holland chapter that was not obtained in this research, and a later book draft’s simplified Sarsa comparison points to unread Wilson 1994 details. Those later forms are not exact aliases of the selected version. No first-use priority, universal benchmark advantage, full later-version equivalence, author-code inspection or experiment reproduction is claimed.
Artificial Intelligence Ontology (AIO) Grounding
Mapped AIO Classes
| AIO Target Class | Mapping Relation | Mapping Rationale |
|---|---|---|
AIO:ReinforcementLearning
Reinforcement Learning
|
related_match | External payoff and inter-rule payments adapt rule strengths without requiring labeled corrective input/output pairs. This connects the credit-assignment procedure to the pinned reinforcement-learning task; it asserts neither exact identity nor subclassing of the whole task, an MDP or Q-learning specification, or an exploration guarantee. |
Evidence Sources & Primary Literature
1 Source| Source ID | Publication / Document | Type / Access | Reference & Checksum |
|---|---|---|---|
holland1985
|
John H. Holland
|
primary paper
full_text
|
sha256:8ec53f4de18e…
|
Curation Provenance
Curator: Codex
Method: ai_assisted
Model: GPT-6
Created: 2026-10-15T15:40:28Z
Updated: 2026-10-15T15:40:28Z
Source File:
data/curated/HollandBucketBrigade.yaml