intelproducts — Intelligence Products — Repo Digest

The published output contract of the Intelligence Platform: versioned, immutable intelligence packs that downstream repos consume. Produced by PersonalOps/FIP; this is layer 3 (Intelligence Products) in the ecosystem model.

What it is

“Published intelligence products for the Inexis / PersonalOps ecosystem, kept separate from the platform that produces them.” (README.md). It holds intelligence-packs/ (the data — versioned, immutable, machine-consumable packs) and skills/ (consumer skills that consuming repos use to act on the packs).

Why it exists

Downstream applications need a stable, versioned intelligence contract, not ad-hoc copies of the founder’s knowledge. Separating the published products from the platform that produces them lets consumers pin a version and treat intelligence as an immutable dependency — additive changes land as v1.x in place, structural changes as a new v2 directory. This is the ecosystem’s “knowledge referenced, never owned” principle made concrete.

At a glance

Business capability provided

Intelligence as a versioned, immutable product — a machine-consumable contract that turns the platform’s knowledge into dependable inputs for apps and agents.

Technical responsibilities

• Hold immutable, versioned packs grouped by domain.
• Provide consumer skills that operate on the packs.
• Preserve the Stage-1 → Stage-3 contract each pack encodes.
• Enforce versioning discipline (additive → in place; structural → new version dir).
• Not: producing intelligence (that’s FIP), or consuming it.

Core concepts

Key workflows

1. Publish — PersonalOps builder skills author a pack and publish it here (immutable).
2. Pin & consume — a consuming repo pins a pack version and uses the matching consumer skill.
3. Evolve — re-run the builder skill in PersonalOps; publish the next version (never edit in place structurally).

Technologies used

• Markdown + structured pack files (manifests, rule-packs, runtime-packs, corpus, runs).
• Distributed to consumers via git submodule (e.g. leadplatform/vendor/intelproducts).
• Consumer skills in the Agent Skills format (SKILL.md).

Major modules / components — pack families

Capabilities

• intelligence-packaging · versioned-contract · consumer-skills

Upstream dependencies

Downstream consumers

• leadplatform — vendors this repo as a pinned git submodule (vendor/intelproducts, read-only contract); uses proposal-generator.
• outreachagent — consumes outreach-messaging skills → commercial-opportunity recommendations.
• OpenClaw / Hermes / MCP consumers — named as future programmatic consumers in pack-manifest.md.

Major interfaces & integration points

• Consumes: published packs from PersonalOps.
• Exposes: immutable versioned packs (data) + consumer skills (behaviour) — the read-only contract downstream repos pin.

Reusable assets exposed to other repositories

• The intelligence packs themselves (proposal, website-assessment, cinnamon-stories, outreach-messaging).
• The consumer skills that act on them.
• The pack contract & versioning convention (immutable, pin-a-version).

Architectural decisions

• Products are separated from the platform that produces them (producer/consumer split).
• Packs are immutable and versioned (additive vs structural change rule).
• Portal-level modelling: ADR 0003.

Architecture snapshot

graph LR
    FIP[PersonalOps/FIP<br/>builder skills] -->|publish immutable| PK[(intelligence-packs<br/>versioned)]
    PK --> SK[consumer skills]
    PK -->|pinned submodule| LEAD[leadplatform]
    SK --> OA[outreachagent]
    PK -.future.-> OC[OpenClaw / MCP]

Current maturity

Operational (as a data contract). Rationale: multiple packs are published across four domains and are already consumed by leadplatform (pinned submodule) and outreachagent. It is “operational” in the contract sense — a stable, versioned dependency — rather than a running service. (Source: README.md, consumer repos.)

Roadmap

• New pack domains as the knowledge estate grows; new versions as builder skills evolve.
• Wire OpenClaw / Hermes / MCP programmatic consumers (future, per pack-manifest.md).

Known limitations

• Packs are only as fresh as the last builder run in PersonalOps (no live sync).
• Some domains have packs but no consumer skill yet (website-assessment, cinnamon-stories).
• Value depends on downstream discipline in pinning versions.

Future opportunities

• MCP-server access to packs for agent consumers.
• Feedback of consumption outcomes into pack quality (the future Hermes loop).

Relationship to the wider AI venture ecosystem

Layer 3 (Intelligence Products) — the published output of the Intelligence Platform (layer 2), consumed by Applications & Agents (layer 4) and, through them, the Ventures (layer 5). See Intelligence Platform architecture and the Portfolio Overview.

Links

• Source: local git repo intelproducts (private)
• Platform doc: Intelligence Platform
• Producer: PersonalOps/FIP
• Registry row: repo registry