coulomb-research/seed/CoulombResearchKernel.md

Coulomb Research Kernel

Purpose

This document defines the smallest conceptual kernel required for Coulomb Research.

The kernel is intentionally smaller than a scientific institution. It contains only those primitives needed to support a recursive research process.

1. Cybernetic Model

The object-level loop is:

observe
  ↓
model
  ↓
criticize
  ↓
intervene
  ↓
observe consequences
  ↓
update model

The meta-level loop is:

observe research process
  ↓
compare outcomes
  ↓
modify tools / incentives / protocol
  ↓
observe effects
  ↓
retain, revise, or revert

A Coulomb implementation should support both loops explicitly.

2. Core Primitives

2.1 Actor

An addressable participant capable of research-related action.

Examples:

• human,
• agent,
• collective,
• organization.

The kernel does not assign epistemic authority based on actor class.

2.2 Proposition

An addressable assertion, conjecture, prediction, explanation, question-framing, or model statement.

Examples:

• "Architecture A has lower catastrophic forgetting than B under condition X."
• "Observed effect Y is caused by mechanism Z."
• "Which mechanism explains anomaly Q?"

A proposition may be uncertain, contested, superseded, or unresolved.

2.3 Evidence

An observation or artifact that bears on one or more propositions.

Examples:

• measurement,
• dataset,
• experiment log,
• simulation output,
• proof,
• source,
• code,
• image,
• testimony.

Evidence should preserve provenance and should be content-addressable where practical.

2.4 Action

An intervention intended to reduce uncertainty, test a proposition, produce evidence, or create a reusable research artifact.

Examples:

• run an experiment,
• search literature,
• reproduce a calculation,
• build a prototype,
• collect a dataset,
• inspect a proof,
• conduct an interview,
• replicate an external result.

A project is a coordinated set of Actions, not a kernel primitive.

2.5 Resource

A scarce capability consumed, reserved, or transferred in order to perform Actions.

Examples:

• money,
• compute,
• equipment,
• data access,
• laboratory capacity,
• human attention,
• agent runtime,
• permissions.

A grant is an allocation of Resources toward Actions, not a kernel primitive.

3. Core Relations

The initial relation vocabulary should remain intentionally small.

Actor relations

Actor --proposes------> Proposition
Actor --performs------> Action
Actor --produces------> Evidence
Actor --allocates-----> Resource
Actor --attests-------> Object

Proposition relations

Proposition --supports--------> Proposition
Proposition --challenges------> Proposition
Proposition --depends-on------> Proposition
Proposition --extends---------> Proposition
Proposition --supersedes------> Proposition
Proposition --tested-by-------> Action

Evidence relations

Evidence --bears-on-----------> Proposition
Evidence --produced-by--------> Action
Evidence --derived-from-------> Evidence

Action relations

Action --consumes-------------> Resource
Action --produces-------------> Evidence
Action --tests----------------> Proposition
Action --depends-on-----------> Action

Relations should be typed, attributable, and versionable.

4. Provenance

Every material research object should expose:

• creator or extractor,
• creation time,
• source,
• version,
• transformation history,
• relevant model/toolchain if agent-generated,
• input references,
• confidence or uncertainty where appropriate,
• verification state.

The system must distinguish between:

SOURCE ASSERTS P

and:

COULOMB ACTOR X ASSERTS P

and:

EVIDENCE E SUPPORTS P

These are not interchangeable.

5. Research Objects as Derived Views

The following are deliberately outside the kernel:

• Paper
• Project
• Research Program
• Experiment
• Review
• Grant
• Journal
• Conference
• Preprint
• Dataset publication
• Reputation score
• DAO
• NFT
• Research collective

They may be represented as:

• projections over core objects,
• workflows,
• user-interface concepts,
• interoperability containers,
• coordination conventions,
• smart-contract structures.

6. Reputation

The kernel should preserve contribution events rather than maintain one canonical score.

Examples:

actor proposed proposition
actor produced evidence
actor challenged proposition
actor completed replication
actor correction was accepted
artifact was reused
prediction succeeded

Reputation functions should be derived from these events and may differ across communities and purposes.

7. Knowledge State

Coulomb should avoid a single truth bit.

Useful proposition states may include:

• conjectural,
• active,
• contested,
• supported,
• contradicted,
• superseded,
• unresolved.

These are summaries over graph state, not immutable labels.

8. Research Daemons

Agentic services may operate over the kernel.

Suggested roles:

• Scout
• Critic
• Synthesizer
• Replicator
• Cartographer
• Historian
• Allocator
• Auditor
• Meta-Learner

Daemons must remain inspectable and replaceable.

9. Decentralization Boundary

Prioritize decentralization where it increases resilience, portability, independent verification, or freedom to fork.

Suggested model:

OFFCHAIN
- research graph
- discussions
- datasets
- models
- mutable workspaces
- most AI inference

OPTIONALLY ONCHAIN
- identity attestations
- content commitments
- resource transfers
- scarce rights
- selected governance events

Blockchain is not required for ordinary research data.

10. Kernel Test

A proposed feature belongs in the kernel only if removing it prevents the core research loop from functioning.

If it merely improves convenience, discovery, prestige, publishing, governance, monetization, or presentation, it belongs outside the kernel.