TinyCog: transferable scan

Status: memory-first and source-ungrounded Recall confidence: low

Remembered model

I remember only that TinyCog was presented as a small symbolic cognitive-architecture project. I cannot reliably state its components, execution cycle, authors' aims, or whether the implementation is substantial enough to support the category. The Wikipedia label "symbolic" and the name's promise of smallness are not adequate grounds for reconstructing a design.

The only responsible transfer scan is therefore conditional: if TinyCog intentionally pursues a minimal executable architecture, what could minimality teach us?

Provisional ontology

No TinyCog-specific ontology is asserted. A minimal-architecture investigation would look for:

  • Primitive state types: the smallest distinct forms of memory or control.
  • Cycle: the minimal transition that turns state into another cognitive action.
  • Extension point: how additional capabilities compose without changing the core.
  • Executable specification: code small enough that architectural claims can be traced end to end.
  • Adequacy boundary: tasks the core explicitly can and cannot support.
  • Omitted mechanism: a capability delegated to environment, model, developer, or user.

Transfer candidates

  • TINY-1 — build minimal reference loops as adequacy probes. A tiny executable version of a proposed memory or improvement loop can reveal missing state transitions more effectively than another architecture diagram.
  • TINY-2 — count delegated machinery. Minimality is false when complexity is merely hidden in an LLM, database, framework, or human operator. List external capacities alongside core primitives.
  • TINY-3 — require a declared competence boundary. A small system is valuable when it identifies the smallest mechanism sufficient for a target phenomenon, not when it implies general cognition from a toy demonstration.
  • TINY-4 — prefer traceability over feature count in reference implementations. A compact implementation can serve as an executable semantics for terms such as candidate, evaluation, retention, and activation.
  • TINY-5 — grow only after a failing case. Add a primitive when a target task demonstrates that the current ontology cannot express the needed distinction, following YAGNI at the architecture level.

Method worth borrowing

Use a ladder of minimal counterexamples. Implement the smallest loop claimed to satisfy one Commonplace mechanism, such as proposal-selection-retention. Test a case requiring each proposed distinction. If removing a state type does not change behavior on any case, it has not earned architectural status; if a failure cannot be represented, the minimal core is inadequate.

Non-transfer and failure modes

  • These candidates are motivated by minimal executable systems generally, not established TinyCog mechanisms.
  • Toy tasks can make an architecture look complete because the environment supplies unacknowledged intelligence.
  • Small code is not automatically clear semantics; names can conceal large host-language or model behavior.
  • Minimality can become aesthetic austerity that blocks necessary provenance, lifecycle, or authority state.

Grounding questions

  1. What problem was TinyCog designed to demonstrate?
  2. What are its actual primitive representations and control cycle?
  3. Which capabilities are implemented internally versus delegated?
  4. Is there a paper, maintained codebase, or worked evaluation sufficient for architectural analysis?