freedom-intelligence/history/InitialExploration.md
tegwick b5f911140b Establish Freedom Intelligence lab foundation and baseline research.
Add INTENT/SCOPE, daily-brief playbook, activity-core definition (disabled),
workplans FI-WP-0001..0003, baseline field survey with open-weight collection
recommendations, and inventory catalog candidates for the model reserve.
2026-07-24 00:15:27 +02:00

12 KiB
Raw Permalink Blame History

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 AD 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.

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 pricecapability 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):

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 AD keep both loops pointed at capability, cost, specialization, and safe agent operations.


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