Source code and resources

Open source status

The Nika OS kernel itself is currently a private R&D repository. It is a differentiation primitive for BCUB3 — it stays closed for as long as the architecture stabilizes and the security invariants are sufficiently battle-tested.

In parallel, several utility components are progressively released as open source on the Powwpol organization. The list below reflects the state as of 22 May 2026.

Public repositories

Repo	Description	License
mempalace	Top-rated memory system on public benchmarks. Theoretical basis of the PALACE PROTOCOL.	MIT
strauss-pilotage	Parametric 3D-printable enclosures for IR + T°/RH sensor piloting (ESP32, ESP-NOW). FreeCAD CAD.	MIT
datagouv-skill	Official skill to interact with the data.gouv.fr portal from an LLM agent.	MIT
datagouv_client	Python wrapper of the data.gouv.fr API.	MIT
csv-detective	Automatic inspection of tabular files (csv, xls-like) to guess column contents.	MIT
api-meteo	Provider-agnostic weather API wrapper.	MIT
fr-format	Validation of French-format strings (SIRET, IBAN, postcode, etc.).	MIT
ui-ux-pro-max-skill	Skill that brings design intelligence to UI/UX construction.	MIT
chrome-devtools-mcp	MCP server to drive Chrome DevTools from an agent.	MIT
bcub3-site	The site on which you are reading this documentation. Astro, static, deployed on GitHub Pages.	MIT

Private components

The following components stay private. This section lists them to document what exists in the system, without giving access to the code.

Component	Why private
nika-os	Main kernel. Active R&D, differentiation primitive.
nika-os-core / nika-os-private	Private kernel layers: routing, GEPA tournament engine.
Nika	Historical pre-kernel code, archived for traceability.
nika-agent / nika-kernel / nika-memory	Alternative runtime (other CLI) and its dedicated memory.
nika-system-inventory	Infrastructure inventory (secrets, IPs, services).
nika-backups-dr	Disaster-recovery backups encrypted with age.
Linkedin_mcp	LinkedIn MCP server, contains embedded credentials.
qonto-mcp-server	Banking MCP server, contains embedded credentials.

Patents and publications

Three patents have been filed at INPI by Paul Obara:

Code	Filing date	Domain
sWELU (FR2513029)	2026	Neural activation function for small models
KTW B1	2026-01-08	Predictive industrial piloting Kelly + Weibull
KTW B2	2026-01-08	Closed-loop probabilistic piloting + dynamic setpoint reframing

The patents are described in accessible terms (without formulas) on the Lab main page. This Nika OS documentation assumes the reader has already gone through these public presentations.

External references

The works below directly inspired the Nika OS architecture. This section lists them to enable a critical reading of the system.

• GEPA: Genetic-Pareto evolution for prompt optimization (2025) — directed prompt evolution method used for the harness.
• Kelly J.L., A New Interpretation of Information Rate (1956) — original Kelly formula, applied here to correction dosing.
• Taguchi G., Quality Loss Function (1989) — quadratic loss function used to translate a measurement deviation into cost.
• Weibull W., A Statistical Distribution Function of Wide Applicability (1951) — distribution used to estimate whether a deviation is a drift.
• Taleb N., Antifragile (2012) — conceptual framework for doctrine 1.
• Model Context Protocol (modelcontextprotocol.io) — protocol used by all MCP servers.

How to contribute

Public components accept external contributions following the standard GitHub workflow:

1. Open an issue to discuss the change before writing code.
2. Fork, branch (feat/... or fix/...), make atomic commits.
3. PR to main with a clear description of the motivation.

PRs that touch kernel invariants (security, brand, doctrines) require explicit human validation. Purely utility PRs (typos, doc fixes, test additions) are merged quickly.

For any architecture or BCUB3 integration question: info@bcub3.com.

Open source vs personalized config — the publication challenge

A question that comes up regularly: why does the Nika OS kernel stay private while so many utility components are released? The answer is in one sentence: what actually runs today is deeply personalized.

The Nika OS instance orchestrating daily work at BCUB3 knows:

• The customers (qonto API keys, SharePoint identifiers, tenant-specific Microsoft 365 accounts).
• The internal conventions (project codes, project references, team member names, business processes).
• The operator’s preferences (preferred CLI, communication tone, time zones, accumulated GEPA doctrines).
• Encrypted credentials to a dozen third-party APIs.

Publishing this kernel as-is would be both useless (nobody else has the same config) and dangerous (data leak).

What the open source version must provide

For a new user to install Nika OS and actually use it, the public release must separate two kernel layers and the config:

1. Paul’s personal kernel (BCUB3) — the operational instance that runs here, accumulated over 6+ months of usage, deeply personalized with customers, conventions, credentials, accumulated GEPA mutations. Stays private, will never be released as-is.

2. The agnostic base kernel — orchestrator, primitives (skills, hooks, MCP, memory, IPC), multi-CLI router, GEPA tournament engine, KTW controller. Everything that is common to all users. Released progressively after stabilization.

   Particularity: this kernel is alive. As soon as a new user installs and uses it, their anonymized operational traces can feed a common improvement loop (with their explicit consent via the wizard). Recurrent patterns, useful GEPA mutations, skills requested by several tenants: anything cross-tenant reusable progressively enriches the agnostic kernel.

3. The tenant-specific config — empty at install, filled by the wizard via OAuth and API key entry. Each user builds their own personalized layer, never released.

Improvement cycle of the agnostic kernel

flowchart LR
    P["Paul (BCUB3)<br/>personal kernel"] -.->|"useful primitives<br/>extracted + anonymized"| K["Agnostic kernel<br/>open source"]
    U1["Tenant 1"] -->|"install + use"| K
    U2["Tenant 2"] -->|"install + use"| K
    UN["Tenant N"] -->|"install + use"| K
    U1 -.->|"patterns / mutations<br/>with consent"| K
    U2 -.->|"patterns / mutations<br/>with consent"| K
    UN -.->|"patterns / mutations<br/>with consent"| K
    K -->|"v0.2, v0.3, …<br/>versioned release"| GH["Powwpol/nika-os<br/>(public progressively)"]

    classDef perso fill:#E99971,color:#F5F1E8,stroke:#C97A55;
    classDef tenant fill:#F5F1E8,color:#2C3E42,stroke:#7DB5A5;
    classDef kernel fill:#7DB5A5,color:#F5F1E8,stroke:#5E9384,stroke-width:2px;
    classDef repo fill:#2C3E42,color:#F5F1E8,stroke:#1A262A;
    class P perso;
    class U1,U2,UN tenant;
    class K kernel;
    class GH repo;

This collective enrichment is strictly opt-in: no user data leaves their tenant without explicit consent. What flows up to the agnostic kernel is only:

• Architectural patterns (e.g. “10% of tenants spawn a freecad pod → deserves a native skill”).
• Validated GEPA mutations that improve a prompt without revealing the tenant’s private context.
• Bugs / improvements reported via GitHub issues.
• MCP servers that tenants have created via mcp-builder and want to share (e.g. a wrapper API of a public service).

This architecture personal kernel ↔ agnostic kernel enriched by the community is the path for Nika OS to remain useful to BCUB3 while becoming a product that others can adopt and evolve together.

The 1-click to connect the user’s IS

The operational challenge of open source is therefore: how does a user who does not have our config connect their own IS to Nika OS in a few clicks? The answer rests on two existing primitives, exposed in the install wizard:

Case	Primitive	User action
IS API supports OAuth	oauth-mcp-builder	Click “Connect [Google / Microsoft / GitHub / etc.]” → OAuth consent → MCP server generated + optional companion skill
IS API has an API key	apikey-mcp-builder	Paste the key in the wizard (encrypted age) → Python wrapper generated + endpoints exposed as MCP tools
Custom IS without documented API	api-to-mcp (mcp-builder)	Point the wizard to the doc (URL, OpenAPI file, README markdown) → Opus / Mistral generates the MCP wrapper in a few minutes

In the three cases, the result is the same: a functional MCP server, loaded into the kernel without restart, immediately usable from pods. The wizard also preserves idempotence — re-running the wizard on an existing tenant adds / updates MCPs without breaking the running config.

Release roadmap

Component	Release status	Why
Generic kernel (orchestrator + primitives)	To release after stabilization	Useful layer to any user
oauth-mcp-builder + apikey-mcp-builder	To release alongside the kernel	Without it, kernel useless to a third party
CLI adapters (Claude/Mistral/Gemini/Hermes)	Released progressively	Useful for the CLI community
Skills (dataviz, freecad-pilot, harvest-linkedin, etc.)	Released case by case	Not always relevant outside BCUB3
Install wizard (web page + OAuth flow)	Released alongside the kernel	Core of the “1-click” promise
Tenant config (API keys, accumulated GEPA doctrines, memory)	Never	Personal data
KTW / sWELU patents (algos as tools)	Articles + public demos	The mathematical content is published, the proprietary implementation stays internal

This separation is the precondition to take Nika OS from an internal BCUB3 tool to a product usable by others without giving up security or the value of proprietary invariants.