freedom-intelligence/history/InitialExploration.md

# Freedom Intelligence — Initial Exploration

**Date:** 2026-07-23  
**Repo:** `freedom-intelligence`  
**Scope affiliation:** Coulomb / NetKingdom  
**Status:** founding conversation recorded  
**One-liner (repo):** *The just in case open weights model lab*

---

## Why this document exists

This is a greenfield project. There is no INTENT.md, SCOPE.md, or workplan yet —
only a README, LICENSE (MIT, © 2026 coulomb), and git scaffolding.

This file captures the **founding conversation** that defines why the lab exists,
what it watches, and what durable assets it should accumulate. Later INTENT/SCOPE
and workplans should refine from here, not reinvent the charter.

---

## Founding intent

Establish a standing capability to:

1. **Produce a daily research brief** on interesting progress in the AI models,
   methods, harness, and tooling space.
2. **Collect and retain open-weight models** on lab backup storage so they remain
   available for possible future local training or operations — *just in case*.

The lab sits inside the broader Coulomb NetKingdom landscape: secure, inspectable,
homelab- and fleet-accessible infrastructure where agentic systems and open
security tooling already grow. Freedom Intelligence is the **intelligence sensing
and model-reserve arm** of that landscape — not a product UI, not a cloud SaaS
wrapper, and not a commitment to run every frontier model locally.

---

## Daily research brief — mandate

The primary operating rhythm is a **daily research brief**: a curated digest of
what moved the needle, not a raw news firehose.

### What “interesting progress” means here

Progress that changes (or could soon change) **capability, cost, accessibility,
or operability** of intelligence systems we care about — especially where those
systems can be run, specialized, orchestrated, or reserved under our own control.

### Brief design principles (initial)

| Principle | Meaning |
| --- | --- |
| **Signal over noise** | Prefer releases, benchmarks, methods, and tooling shifts that matter for A–D below |
| **Actionable for the lab** | Note whether something is relevant to monitoring, local/edge use, training, or harness work |
| **Price and access aware** | Track not only SOTA quality but cost, license, and where weights can be obtained |
| **Reproducible sources** | Cite primary sources (papers, model cards, release notes, repos, pricing pages) |
| **Durable archive** | Briefs live in-repo (or linked inventory); they form a longitudinal memory of the field |
| **Just-in-case bias** | When an open-weight artifact is rare, high-leverage, or at risk of vanishing, flag for collection |

### Suggested brief sections (starting shape)

Not every section every day — only when there is signal:

1. **Headline deltas** — what actually changed
2. **Frontier & commercial** — capabilities, benchmarks, price moves (axis A)
3. **Edge / local / open** — runnable intelligence at low cost (axis B)
4. **Training & specialization** — methods and tooling for pre-/post-/domain work (axis C)
5. **Harness & fleet** — agents, orchestration, sandboxing, multi-agent ops (axis D)
6. **Collection candidates** — open-weight models or datasets worth parking on backup storage
7. **Lab implications** — optional: what (if anything) the lab should do next

Format, cadence automation, and distribution (inbox, wiki, State Hub event) remain
open design choices.

---

## Special interest axes

The monitoring and reporting charter is multifold. These four axes are the standing
lens for both the daily brief and longer research notes.

### A — Frontier model capabilities, benchmarks, and price trends

**Watch:**

- Best-of-class closed and open frontier models (reasoning, code, multimodal, long context, tool use)
- Benchmark suites and their gaming/validity debates (e.g. SWE-bench, Arena, GPQA, internal harness scores)
- API price-per-token and effective cost-per-useful-task trends
- Latency, rate limits, regional availability, and enterprise terms that affect operational use
- Distillation / smaller “near-frontier” offerings that shift the price–capability curve

**Lab value:** know when paid frontier is the right tool, when open alternatives close the gap,
and when price collapses make new workflows economical.

### B — Edge intelligence and low-cost open / local compute

**Watch:**

- Small and mid-size open-weight models that run on consumer or lab GPUs, NPUs, and CPUs
- Quantization, speculative decoding, KV-cache, and inference runtimes (vLLM, llama.cpp, MLX, TensorRT-LLM, etc.)
- Hardware-accessible stacks: single-box homelab, mini-PC, older datacenter cards, Apple silicon, edge SBCs
- Specializations: code, RAG, embeddings, rerankers, speech, vision-on-device
- Licensing that actually allows local ops and redistribution of derived artifacts

**Lab value:** independence from continuous cloud spend; privacy; offline and sovereign operation;
honest capability floors for NetKingdom-local agents.

### C — Homelab-accessible training and domain specialization

**Watch:**

- Pre-training, continued pre-training, mid-training, SFT, preference optimization (DPO/ORPO/…), RL/verifiers
- LoRA / QLoRA / adapters, mixture-of-experts fine-tunes, model merging, unsloth-class efficiency tricks
- Datasets and data pipelines that fit homelab budgets (synthetic data, filtering, domain corpora)
- Recipes that fit **our** hardware class — not only hyperscale recipes
- Evaluation for domain specialization (not only public leaderboards)

**Lab value:** ability to specialize open bases for Coulomb / NetKingdom domains
(security, ops, railiance, tenant workflows, etc.) without assuming a full training cluster.

### D — Agent harnesses, orchestration, sandboxing, and fleet management

**Watch:**

- Agent frameworks and harnesses (tool loops, planning, memory, multi-agent protocols)
- Orchestration of long-running and multi-step work (workplans, fleets of workers, queues)
- Sandboxing and containment of agent side effects (filesystem, network, credentials, blast radius)
- Fleet management: provisioning, identity, observability, cost control, policy for many agents
- Adjacent NetKingdom capabilities already in the landscape (e.g. sand-boxer, ops-warden, state-hub, kaizen agents)

**Lab value:** intelligence is useless without safe, operable delivery. This axis ties model progress
to how NetKingdom actually runs agents.

---

## Open-weight model collection (backup storage reserve)

### Purpose

Use **lab backup storage facilities** to build a **deliberate collection of open-weight models**
(and, where justified, companion tokenizers, adapters, and evaluation fixtures) that we might
later reuse in a **local training or operations facility**.

This is a **reserve**, not a mirror of the entire Hub:

- Prefer models that score high on axes B/C or that are strategically useful even if large
- Prefer clear open licenses and stable provenance (Hugging Face, official org releases, mirrors with checksums)
- Prefer artifacts that are hard to re-obtain later (takedowns, license flips, silent re-uploads)
- Store enough metadata to rehydrate: source URL, revision/hash, license, size, hardware class, brief notes

### Collection principles (initial)

| Principle | Detail |
| --- | --- |
| **Just in case** | Collection is insurance and optionality, not an obligation to serve every model |
| **Backup-class storage** | Place weights on facilities already intended for durable bulk retention; do not fill hot cluster disks |
| **Catalog in-repo or adjacent** | Git holds inventory/metadata; blobs stay on backup media |
| **Integrity** | Checksums, signed manifests where available, recorded download date and source revision |
| **License gate** | Only collect what license and terms allow for offline retention and intended reuse |
| **Prioritization** | Daily brief feeds candidates; human or workplan approval gates large pulls |
| **Reuse paths** | Future consumers: local inference, fine-tuning experiments, offline eval, air-gapped ops |

### What is explicitly out of scope (for now)

- Hosting a public model mirror or CDN
- Guaranteeing 24/7 inference for the full collection
- Training from scratch at frontier scale
- Collecting closed weights or scraping in violation of terms

---

## Relationship to Coulomb / NetKingdom

| Concern | Freedom Intelligence role | Adjacent systems (examples) |
| --- | --- | --- |
| Field sensing | Daily brief + research notes | State Hub progress/inbox for distribution later |
| Model reserve | Open-weight collection on backup storage | disaster-control / backup facilities; storage ops |
| Local intelligence | Informs what can run on lab hardware | sand-boxer, agent harnesses, local runtimes |
| Security posture | Prefers inspectable open stacks | net-kingdom, kings-guard, openbao identity patterns |
| Domain specialization | Future fine-tunes for Coulomb domains | domain repos that need specialized assistants |

Freedom Intelligence does **not** replace NetKingdom security or ops products. It supplies
**awareness and optional local intelligence assets** those systems may eventually consume.

---

## Current repo state

**Founding (2026-07-23):** LICENSE, README, this exploration only.

**Foundation files initiated (same day):**

```text
freedom-intelligence/
├── INTENT.md
├── SCOPE.md
├── README.md
├── LICENSE
├── briefs/
│   ├── README.md
│   └── _template.md
├── inventory/
│   ├── README.md
│   ├── schema.yaml
│   ├── collection-policy.md
│   └── catalog/
├── docs/
│   ├── backup-storage-policy.md   # path/quota TBD
│   └── state-hub-delivery.md      # stub, not wired
└── history/
    └── InitialExploration.md
```

Still open: first production brief, pinned backup path/quota, catalog entries, automation.

---

## Open questions for the next design pass

1. **Brief cadence and owner** — fully automated scrape + human edit, agent-produced draft, or operator-written?
2. **Brief storage layout** — e.g. `briefs/YYYY/MM/YYYY-MM-DD.md` vs weekly rollups?
3. **Sources allowlist** — which sites, arXiv categories, HF orgs, pricing pages, and X/GitHub signals matter first?
4. **Backup storage location** — exact path/share/bucket, retention, encryption, and capacity budget for weights?
5. **Inventory schema** — YAML/JSON catalog fields for each collected model revision?
6. **Hardware envelope** — what GPUs/CPU hosts define “homelab accessible” for axes B and C?
7. **INTENT/SCOPE split** — formalize aspirational vs near-term deliverables after first brief prototype?
8. **State Hub registration** — when (if) this domain/repo becomes a tracked hub domain or remains a satellite under netkingdom/coulomb?

---

## Suggested near-term follow-ups

| Priority | Action | Status |
| --- | --- | --- |
| 1 | Draft `INTENT.md` / `SCOPE.md` from this charter | **Done** (foundation) |
| 2 | Define brief template + layout under `briefs/` | **Done** (template; first filled brief still open) |
| 3 | Document backup storage target and capacity policy | **Done** (policy; path/quota TBD pin) |
| 4 | Define model inventory schema and collection approval rule of thumb | **Done** |
| 5 | Optionally wire brief delivery into operator inbox / State Hub | **Stub only** (`docs/state-hub-delivery.md`) |

---

## Central proposition

> **Freedom Intelligence is the Coulomb NetKingdom lab for watching the AI capability frontier
> with a bias toward open, local, and operable intelligence — and for holding a durable
> open-weight reserve so useful models remain available when we need to train or run them ourselves.**

The daily research brief is the **sensing loop**.  
The open-weight collection on backup storage is the **strategic reserve**.  
Axes A–D keep both loops pointed at capability, cost, specialization, and safe agent operations.

---

*Recorded from the founding project conversation, 2026-07-23.*