The application factory

The longer-term objective of Cosmic Bull: accept an application objective and decide how to satisfy it, rather than defaulting to writing new code.

The goal is not maximum code generation. The goal is useful applications produced through maximum appropriate reuse and rigorous verification.

The four strategies

Given an objective, Cosmic Bull chooses among four, in this order of preference:

1. Reuse an existing primitive

A /p/ package already does this, correctly, and is already deployed. Import it.

This is the cheapest outcome by a wide margin: no new audit surface, and the imported code arrives with a track record. grants and market both reached production this way for their value handling — they import coinio and feeledger, which were already live and already audited by the time those realms were written.

2. Compose existing realms and packages

The capability exists, spread across two or more live components. Wire them together rather than reimplementing either.

Composition across /r/ boundaries is more expensive than /p/ reuse — it introduces cross-realm call semantics, and therefore caller-identity and readonly-taint questions — but it is still far cheaper than new infrastructure.

3. Adapt an existing implementation

Something close exists, but needs porting to current chain semantics, remediation of security findings, or a different asset/authority model.

Port it; do not redesign it. The discipline here is specific:

• transformations are mechanical and occurrence-pinned — every substitution is counted, and the count is asserted
• the port is proven green before any remediation is layered on, so that every later test failure is attributable to the remediation alone
• remediation changes security properties, never the application's identity

All five GitHub-pipeline applications are strategy 3. See catalog/applications.md.

4. Create genuinely new infrastructure

Only after 1–3 have been searched and recorded as insufficient — with the evidence committed in a DISCOVERY.md.

Strategy 4 is the expensive one and it is the last resort by design. Every new line is new audit surface, and on an immutable chain a mistake is permanent.

Cosmic Bull has used strategy 4 four times, each with recorded reasoning: feeledger, coinio, duebook and permbook. Reuse is what justifies having written them, and the chain-computed consumer lists in catalog/portfolio.json (proved by C7) are the authority: feeledger is imported by eight deployed realms (bounties, bounty_panel, coindemo, grants, market, service_market, subscriptions, vault); coinio by six (bounty_panel, coindemo, grants, market, service_market, subscriptions — the deployed bounties and vault v1s predate coinio and do not import it; only their undeployed local vNext trees do). (Corrected 2026-09-23 from a hand-grep "six for both" whose coinio membership wrongly included bounties/vault and which predated the two newest realms.) duebook and permbook each have exactly one consumer, so neither has earned that justification yet, and both records say so. A primitive written once and never reused is a cost, not an asset.

The first two were arrived at by extraction — the same code appeared in several realms first. The second two were arrived at objective-first, which is the riskier route, because there is no repetition to prove the abstraction was needed. permbook is the sharpest case: a live Cosmic Bull realm (permission_registry) already satisfied the literal objective and was recorded as doing so before any argument for building, so the new primitive exists only against one quoted, unworkaroundable property of that realm — caps that are global, shared and unraisable on immutable bytes.

How a strategy is chosen

The choice is an output of the discovery gate, not an input to it. The gate (docs/DISCOVERY_AND_REUSE.md) forces a search across the catalog, the existing sources, the chain, and the public ecosystem, and forces every hit to be classified:

A RELATED hit that is not reused must carry a concrete, specific reason. "Heavier surface than needed" and "marked v0 Unaudited" are concrete; "different style" is not.

Two worked examples from the retroactive review of this portfolio:

• p/coinio vs p/nt/treasury/v0 — treasury abstracts multi-banker dispatch with canonical-impl checks; coinio is a minimal guard-trio/payout/sweep contract with no state. Inspected before building, deliberately not reused, reason recorded.
• p/feeledger vs p/g1n4pl…/bazaar/fee/v1 — overlaps only feeledger's FeeFor; feeledger's substance is the stateful ledger with a conservation contract. Honest admission on the record: had the full enumeration been run before feeledger was built, that fee calculation could have been imported. The gate exists because of that miss.

What "done" means

An application is not done when it compiles, and not done when it deploys. It is done when all of the following are true and written down:

1. Discovery evidence is committed.
2. All RED and material YELLOW findings are resolved — not downgraded.
3. Tests pass against a chain-matched toolchain.
4. The dependency closure the tests used is proven equivalent to the target chain's, by a matching digest pair, with the stdlib residual stated. A passing test alone does not satisfy this — see DEPENDENCY_CLOSURE.md.
5. The deployed bytes byte-match the committed bytes of a named commit, proven before broadcast and re-proven after via vm/qfile.
6. Live reads, live writes, and live attacks are recorded by transaction hash, with abort messages byte-matched to the audited source.
7. Value invariants are checked against real bank state.
8. Sibling live realms are proven untouched.
9. Coverage that was not achieved is stated, with the reason, and correlated to the committed tests that do cover it.

Item 9 is the one that distinguishes a record from a press release.

Items 4 and 5 are deliberately separate, and conflating them was the factory's longest-standing blind spot. Item 5 proves the root is what was committed; item 4 proves the imports are what the chain will actually execute. A realm can satisfy 5 completely while item 4 fails, because the two verify different artifacts against different sources.

Open software, application economics, commercial services

Three layers the factory keeps distinct, because conflating them is how a software project turns into a fee-extraction platform:

• Open software. Every /p/ primitive and every /r/ realm is open source at a public on-chain path, importable by anyone. The reusable code is never the revenue; its free composability is what makes the portfolio worth trusting at all.
• Application economics. Where an application settles real value — a marketplace sale, a released escrow, an awarded bounty — a bounded, explicit, consent-gated protocol fee can be economically natural. The portfolio's fee mechanics (compile-time ceilings, payer consent ceilings, snapshot-at-creation, fee-free refund paths, fees inside the conservation invariant) already exist and are live-validated; whether a production deployment charges them is a per-application decision, and the current Pearl-1 deployments are validation artifacts that mostly charge nothing.
• Commercial services. Work around the ecosystem — building custom applications, auditing third-party code, operating infrastructure — can be paid. Verification results never are: a verification outcome is a function of the code and the chain, not of payment, and no future service may blur that line.

The thesis stays what it was: build, compose, verify and deploy open on-chain software; let economics exist around useful applications and services, never by restricting reusable code.

What the factory is not yet

Stated plainly, so the roadmap is honest:

• Objective → strategy selection is not yet autonomous. The user selects each application; Cosmic Bull then runs the full lifecycle for it. (Updated 2026-09-22: this bullet used to end "…but it has not been exercised from a bare objective with no repository named." It has been, three times — bounty_panel, duebook and permbook were each driven from an objective rather than a named repository; see benchmarks/README.md §7–§9 and pearl/r/bounty_panel/README.md. What remains non-autonomous is only the selection of which application to build, which is deliberate — see the authorization model.)
• Discovery search is keyword- and path-based. It enumerates the target chain exhaustively, but ecosystem search is finite and best-effort. This is why no uniqueness claim is ever made.
• Composition across /r/ boundaries is untested in this portfolio. Every composition so far is a realm importing a /p/. Strategy 2 in its full form — one realm cross-calling another — has not yet shipped.
• The five completed applications are all registries and control-plane primitives. The value-handling realms (vault, bounties, coindemo, grants, market) predate the pipeline. A fund-handling application has not yet gone through the full GitHub → Pearl pipeline.
• Stdlib equivalence between the local toolchain and the node is unverified — and unverifiable from outside. Closure equivalence now covers every chain-stored dependency, but stdlibs execute from the node binary and no RPC surface exposes the node's build. The chain-matched GNOROOT pin is load-bearing for the entire portfolio at once, and it is the largest single unverified assumption in the factory. Closing it needs something the node does not currently publish.