Thoughts

July 2, 2026

July Newsletter#

We skipped June; we've been busy. Here's everything since May.

In this issue:

What We Led — MIRA in Ireland, core-satellite in New York
What We Built — A Resilient Data Future, GREP, Lettuce Compute, SciOS Compute, SciOS Graph, and the MCP ecosystem into PRSM
What We Wrote — The Core-Satellite Model
Where We're Going — DWeb Camp July 07–13, a DOE open source keynote August 4
What We've Seen
IOSP 2026 — Leiden, October 12–15

▶What We Built

A Resilient Data Future — graph.scios.tech

Our Resilient Data Futures narrative argues that research data loss is architectural, and that the fix is what it calls Tier 3 infrastructure, protocol-level distribution where redundancy arises as a byproduct of use instead of depending on any single organization. graph.scios.tech is a working implementation. Scientific records live on IPFS under content identifiers (CIDs), signed by their authors' decentralized identifiers (DIDs), and every link carries both a location and a content hash, so references don't rot and attribution can't be stripped. The whole stack runs on four small servers for $24 a month, and is easily replicated and scaled. Reach out if you'd like to help scale it.

We're expanding it in a workshop at IOSP 2026. Get involved by joining the Resilient Data Futures lab.

GREP — The Great Research Extraction Project

GREP ports the existing literature into frontier infrastructure. In production today, it extracts software mentions from any domain PDF as objects and relationships, and classifies how each piece of software figured in the work (used, created, deposited, or merely mentioned). A voting ensemble of five DeBERTa-based models does the extraction at 85% F1 on our benchmark, and 92% on span identification across a fifteen-domain test set. None of the five is sacred; each slot in the ensemble takes a replacement the day something better exists. The whole thing needs about 32 GB of memory and 45 GB of disk, no GPU, which is what lets volunteer hardware do the work (see Lettuce Compute, below). Expect a less heavy (and slightly less accurate) version in the coming weeks.

We're actively testing extensions of GREP into open science monitoring and MIRA object extraction. The monitoring work currently detects data availability statements and then checks whether data an author claims is open actually resolves; across a corpus of roughly 5,700 papers, 44% carried a statement, 26% claimed the data was openly available, and 16% pointed at data we could confirm was public, matching the claims made in our Resilient Data Futures narrative. The MIRA work turns any PDF into MIRA objects, which you can try at mira-extraction.vercel.app.

Get involved by joining the Modular Research lab.

Lettuce Compute — distributed computing, entering beta

Lettuce Compute is a permissionless distributed computing infrastructure for science. Researchers run a head server and define computations; volunteers run a small client, attach to any head they choose, select a leaf, and crunch on work units. Results are validated through redundancy, and contribution credit is cryptographically signed. There is no approval step and no whitelist; a volunteer generates a key and attaches. The scheduler matches work to machines that can actually run it, whether the task ships as a native binary, a container, or WebAssembly.

Well over 6,000 exaflops of processing power sits idle in the world's existing hardware. Lettuce Compute is how we connect it to scientific work, and we consider it core infrastructure for a reimagined scientific compact. It has spent the last month in alpha with several critical testers (to whom we are eternally grateful); beta opens this month.

Get involved by joining any SciOS Lab.

SciOS Compute — compute.scios.tech

SciOS Compute is Lettuce Compute with the setup done for you. Describe your computation and we stand up the project in under an hour, with distribution, validation, and volunteer onboarding handled. GREP already runs on it. It launches in earnest during the Lettuce Compute beta.

Get involved by joining the Resilient Data Futures lab.

SciOS Graph — workshop.scios.tech

SciOS Graph is a collaborative tool for building shared understanding, running on MIRA and open for anyone to use. It comes in two modes. Mini-MIRA condenses the schema to four node types so a room of newcomers can start thinking in graphs immediately; Full MIRA carries the complete schema for researchers who want the whole medium. We built it for live workshops, where participants add questions, thoughts, and connections from their own devices while a shared projector view updates in real time.

Get involved by joining the Modular Research lab.

PRSM — the MCP ecosystem in one graph

PRSM now crawls the MCP registries and assembles them into a single deduplicated graph. Seven registries feed it (the Official registry, Smithery, Glama, PulseMCP, mcp.so, Nerq, and BioContextAI for biomedicine). As of this writing it holds over 58,000 servers, 74,000 tools, and 26,000 confidence-scored "wrap" edges, each one recording that a specific MCP server lets an AI use a specific dataset, service, or piece of software.

The wrap edges make reverse lookup possible. Pick a dataset and ask what an AI can plug into today. NASA's open APIs are wrapped by 1,186 servers; SQLite by 735, PostgreSQL by 559, arXiv by 198, PubMed's E-utilities by 126, Crossref by 49, OpenAlex by 48.

Run the same question across the NumFOCUS-sponsored projects and the answer gets thin. pandas has 9 servers, SymPy 9, Matplotlib 8, NumPy 6, scikit-learn 2, SciPy 1, and Astropy, xarray, PyMC, seaborn, and GeoPandas sit at zero. (These are confirmed wraps, where the server declares the package as a dependency and names it, so read them as floors; many wrapper repositories haven't been analyzed yet.) The zeros are widely used scientific tools that nobody has wrapped in an MCP server. If you're looking for a way to help research software, that is a very good place to start.

The graph reaches specialist registries too. It carries 62 biomedical servers from BioContextAI (UniProt, Ensembl, PubChem, Open Targets, single-cell tools) and about a dozen Bioconductor community servers pulled straight from GitHub. Know a registry we're missing? There's a suggest-a-source form on the site.

All of it runs on PRSM's existing data layer, the graph that already links publications, repositories, packages, dependencies (declared and hidden), and contributors. Explore it, no login required: prsm.network/demo/mcp.

Get involved by joining the VOWELS lab.

▶What We've Seen

Ellie was in Vancouver this spring for AtmosphereConf, where a workshop explored AT Protocol, the protocol underneath Bluesky, as a home for scholarly work; the keynote described research as a continuous, federated, computable graph of knowledge, and the demos ran discourse graphs and contribution attribution over decentralized identity. The Continuous Science Foundation's working group on modular peer review has met monthly all spring, asking how review and credit can attach to data, methods, code, and figures independently. The Knowledge Graph Conference drew more than a thousand people to Cornell Tech in May, including a symposium track on evidence graphs derived from the literature. People are converging.

Germany's DFG opened a funding line to safeguard endangered data repositories, citing roughly 200 repository closures over the past 25 years, more than half since 2018. A study in Nature Genetics traced the single points of failure in centralized biomedical databases (cyberattacks, funding cuts, political disruption) and held up ELIXIR, the 25-node federation behind Europe's life science data, as the working alternative. EOSC, Europe's open science cloud, added 14 nodes in April and now federates 28.

ICLR, one of the big machine learning conferences, collected just over 76,000 peer reviews for its 2026 cycle, and the AI-text detection firm Pangram Labs flagged about a fifth of them as fully AI-generated. Kubernetes shipped contributor policy in June that requires AI use to be disclosed, bars AI as a co-author, and promises reviewers they are talking to humans. Jazzband, the collective that maintained 84 Python packages serving 150 million monthly downloads, shut down in March; its founder named AI-generated spam contributions among the causes. In every one of these stories, the scarce resource is a person with the judgment to evaluate the work.

The UN held Open Source Week in New York in June, 2,600 participants from more than 120 countries, and UNESCO launched its Open Science Platform there, built on CERN's open repository framework InvenioRDM. We were there, and the appetite for radical change is even stronger in person than it reads in the announcements. Renaissance Philanthropy opened a $20 million fund for open source in the life sciences. Germany's Sovereign Tech Agency began paying open source maintainers a stipend to represent their projects in standards bodies. Wiley booked $49 million in AI licensing revenue this fiscal year, and arXiv and Semantic Scholar both gained MCP servers. Publishers and protocol builders are working out machine access to the scientific record right now, one licensing contract at a time on one path, one open server at a time on the other.

June 30, 2026

Below is a paper describing the Core and Satellite model, four worked examples within the model, and several supporting documents. Work towards at least one pilot core will be presented and workshopped at IOSP 2026.

The Core-Satellite Model#

A judgement-based commons framework for open source and open science.

Problem#

Open source software and open science outputs are produced by communities working in domains advancing missions. A domain is an area of work, like astronomy, cryptography, or genomics. A mission is something being made real from the work done in one or more domains, like detecting mining candidates beyond Earth, securing the world's communications, or advancing precision medicine. Each domain consists of thousands of artifacts — individual projects, packages, datasets, businesses, research efforts... any tangible digital or physical thing — each surfacing different information about itself, its work and outputs, and its domains in a different way. There is no shared interface through which these efforts might coordinate, or how they might be observed, assessed, or evaluated as a whole.

A domain split into thousands of isolated efforts is a domain of thousands of isolated experts, each holding unique expertise and judgment that, if combined within and across domains, would carry each of their missions far further than any of them can alone.

As agents continue to occupy a greater share of the labor of execution, as human knowledge leans more on digital memory, and as code drifts from structured file-trees toward software blobs, judgment, wisdom, and discernment become critical resources only humans can provide. These critical resources are what guide agent orchestration, approach, and design, weigh value, risk, criticality, and priority, spot the gaps, and uphold quality, safety, norms, and dependencies. Today nothing gathers these resources; they stay siloed with the people who hold them, each focused on their individual artifact.

This fragmentation of domain expertise, which scatters the shared judgment a domain depends on, has costs that fall on every participant in the system.

Funders can't make informed decisions across thousands of artifacts that might advance their mission. The judgment they need sits scattered across all of them, with no stable, accountable interface to a domain as a whole, so each artifact has to be evaluated bespoke, and because automated impact and health metrics, both proactive and retrospective, fail at exactly the high-stakes decisions funding requires, that per-artifact due diligence is expensive and doesn't scale.
Maintainers and builders each carry the weight of governance, sustainability, discoverability, and infrastructure alone, when much of that work could be shared across their domain, and the combined judgment that would move the domain forward, reduce duplicated efforts, and advance creative risk-taking in leaps, stays fragmented, locked in the mind(s) behind each individual artifact.
Practitioners and users can't easily find the right artifacts, judge their reliability, or know which are stable versus experimental, what can address their challenge, and what doesn't yet exist, because the judgment that would tell them stays with the experts who hold it, ungathered.
AI agents and the people building with AI face the same problem at higher volume, needing authoritative, vetted, machine-readable knowledge per domain and finding instead an emerging quagmire of skills, harnesses, and models, a quagmire that faithfully replicates exactly what created the existing issues in open source and open science in the first place.

Why now#

Fragmentation in open source and open science is an old problem, and humans have always papered over it with tacit knowledge: why a library is built the way it is and what breaks if you change it, which dependency everything quietly rests on, which approach the field tried and abandoned, what a benchmark actually measures, which fork died three years ago and why. None of that is in the metadata. It lives in social context, cultural memory, and the embodied judgment of people who work in the domain.

The rise of agentic execution makes this approach structurally untenable. Agents cannot access tacit knowledge; they read what's written down. While not ideal, as long as humans were doing the work, the missing layer was a "simple" tax on contributor time. As agents take on more autonomous work, the bottleneck increasingly shifts from raw model capability to the absence of domain curated boundaries the model can rely on.

What an agent needs to operate in a domain — canonical artifacts, vetted skills, evaluation suites, signals about what's trusted and what's deprecated — has to be externalized into structures that are accountable, machine-readable, and maintained by people who actually inhabit the domain. Not all of it externalizes; the emerging role of humans in automated systems is to maintain and surface the parts of the system that resist being written down, and to orchestrate the agents that consume what is. Without this, agents will at best always be behind frontier practices, and at worst confidently output full hallucinations on entirely hallucinated domain stacks.

Maintaining these structures is stewardship, the role that resolves from working on an artifact alone into holding a domain's judgment with others. No one person and no one profession contains a domains complete knowledge, so stewards gather into bodies.

The question is who builds and maintains these bodies, and how, without recreating the gatekeeping problems fragmentation was a reaction to in the first place.

Solution#

The core-satellite model is a commons framework for how open source and open science ecosystems can structure themselves around an unbounded number of slow, stable, accountable cores and a much larger, faster-moving population of satellites that orbit them.

The model is not a new institution, foundation, or platform: existing communities adopt it, new communities form around it, and funders, builders, users, and AI agents all interact through one shared, minimal schema-based interface.

The model exists alongside and in addition to existing OSS foundations and infrastructure (NumFOCUS, Apache, Linux Foundation, etc.). It does not replace them.

The model#

People support missions. Missions depend on artifacts. Artifacts exist within and across domains. An artifact can be a project, package, dataset, business, research effort, or any tangible digital or physical thing.

A core is a group of people that scopes itself within a domain, wrapped around artifacts.

A satellite is an individual or group that scopes itself to a single artifiact, and orbits one or more cores.

A flexible, extensible common schema, akin to an ATProto Lexicon or Google's Open Knowledge Format serves as a coordinating, machine readable interface to the system of cores and satellites.

AstroPy is the closest best example of an existing emergent core: People get behind AstroPy because it serves astronomy in Python as a whole, not because of any one library within it. A domain of that size, with the operational infrastructure AstroPy has developed over the years, can attract the funding, the range of professions, and the sustained attention that no single artifact can, and has proven to greatly advance the missions depending on its domain artifiacts over the years.

Cores

A core is, at its technical minimum, anything that declares itself one by surfacing the common schema. In practice, a core is the embodied judgement of experts within a domain.

The entities that get treated as reputable cores are structured as commons of at least dozens of users, maintainers, builders, business leaders, legal practitioners, governance and policy practitioners, and others that have organized themselves around explicit protocols for governance, operations, and resource flow. Examples of existing emergent core-like entities are: Bioconductor, AstroPy, the Scientific Python project. Future cores might be field-bound (open materials science), horizontal (research infrastructure), or meta (a governance commons).

A core is where people organize within a domain, and their work has two faces. Inward, they hold the domain's judgment, keep its canonical artifacts maintained and current, and steer the agents working in it. Outward, the core is a body surfacing data on its domain and its work. It is a body funders, builders, users, and agents engage when they want to work within the domain, or toward a mission that relies on artifiacts within the domain.

A core's responsibilities might include:

Holding an opinionated judgment on a domain: what is canonical, dependency, trusted, experimental, or dead.
Maintaining stabilized, canonical versions of its domain's artifacts, including software, datasets, methods, and protocols.
Managing in-flow and distribution of funding to the core's domain and the satellites around the core.
Building and maintaining an agentic toolchain for its domain: skills, harnesses, evaluation suites, MCP endpoints, documentation, and best practices that AI agents use when working in the domain.
Certifying or attesting to AI behavior in its domain: which models, agents, and tools are domain-safe; what evaluations apply; what norms hold for AI-generated contributions.
Acting as a partner channel for AI labs that need domain-grounded curation, evaluation, and governance data.
Setting its own internal protocols for governance, finance, and satellite lifecycle.

There is no upper limit on the number of cores in a domain. Cores can be small or large, run well or badly, succeed or fail, merge with each other, absorb each other, or split. The ecology is open and self-organizing.

Because the floor to declare a core is so low, "is this a reputable core?" is never answered by the meta-layer. It is answered by whoever is asking, against what the core surfaces in the schema. Two layers sit above raw self-declaration, and neither is an arbiter:

Endorsements. Any participant can endorse a core, or withdraw a prior endorsement — append-only and attributable.
Computed maturity. Reputable or mature core is a status observers derive from the surfaced data plus its endorsements, not a flag the schema or any registry assigns. Competing algorithms can compute it differently; observers choose which to trust.

So substance is real and it matters, but it is measured downstream by the people and machines deciding whether to rely on a core, never gated at the door.

What a core is not

The floor is the minimal schema record, but the concept of a core is distinct from four adjacent things it may be mistaken for. These are clarifying contrasts, not entry gates. Anything may surface a core record, but conceptually:

A core is not a fiscal host or foundation. NumFOCUS, Apache, and the Linux Foundation host legal and financial entities. A core can take whatever organizational form serves it, whether its own legal entity, a fiscal host it uses, or a program inside an existing one. The wrapper is a choice. What defines a core is the domain judgment it expresses and the services it provides, not the legal shell.
A core is not a registry or package index. PyPI and ecosyste.ms index everything neutrally and make no calls. A core surfaces judgement and opinions defined by its members: canonical versus dead, trusted versus experimental, and so on.
A core is not a standards body. The schema and its open-standards process are the substrate a core consumes and extends. A core speaks the schema; it does not govern it.
A core is not a single artifact. One library or repo surfacing a record is, in spirit, a satellite. What makes an entity read as a core is that it coordinates beyond a single artifact.
A core is not a collaboration of artifacts. It is its own entity, a collaboration is temporary by definition.

Each adjacent object listed above does one piece of the job. A fiscal sponsor moves money. A community organizes people. A registry lists artifacts. A standards body keeps a spec. Real entities already do several of these pieces, and do them well. What none has done is assemble all of them into one body that holds an opinionated view of a domain, stewards its canonical artifacts, governs itself, routes funding, serves the domain to agents, and surfaces all this work through a common schema making its own work comparable to the work of others.

That machine-readable coordination interface on top of the integrated bundle, carried by one community of opinionated experts organized into operational protocols, is what this model names.

What a core is made of

At its core, a core is a community of humans, not a collaboration of artifacts. The canonical and coordinated artifacts are what the people steward, not the members themselves. Dissolve the people and you dissolve the judgement; the core is gone.

A working core needs more than people who write code. A reputable core might contain, at least:

software, data, and other artifact maintainers who steward the canonical and coordinated artifacts;
governance experts who help define and maintain a core's governance protocols;
sustainability and entrepreneurial roles who help interface with funding bodies, maintain any business/sustainability models within the core, carry finance and compliance responsibilities;
domain experts and users who hold the tacit knowledge of the domain, and whose needs, expertise, and judgement steer the core's activities.

Gravity is the ability of a core to attract people, artifiacts, resources, and attention. A reputable core will have high gravity, while a newer core might start with low gravity.

A mature core is an employer and contractor hub, not a volunteer hobby. Funding routed to the core pays its critical maintainers, its coordinators, and its governance and finance people; turning work that was unpaid evenings and making it someone's funded job is much of why a core exists. Where the money comes from is itself a source of gravity: a durable core builds and maintains several funding streams at once — grants across sectors, paid services, and domain judgement/data licensed to AI labs among them — so its survival never rests on a single source of funding.

The core proper is the people who steward the canonical and coordinated artifacts, plus the governance, financial, and operational protocols and roles. A maintainer whose package merely orbits the core is a satellite maintainer, not a core member: in orbit, not inside. As a satellite is accreted or graduated into the canonical layer of the core's domain, its maintainer is drawn into the inner body. A single person running a single orbiting artifact is affiliated with the core, not in it, until their work (and they) are accreted.

Satellites

Most artifacts are satellites.

A satellite is a non-canonical artifact that orbits a core. Often young, experimental, niche, or temporary, examples of satellites might include software packages and libraries, datasets and reference data, agent artifacts, or research projects, methods, and protocols.

Satellites can affiliate with multiple cores simultaneously. A research project working on cross-domain infrastructure, like cryptography, might orbit a research infrastructure core and a digital privacy core.

Core <-> Satellite

Each core defines its own protocol for satellite lifecycle:

insertion - how satellites declare or are recognized as orbiting a core
orbit - what affiliation entails
accretion - the process for adding features/functions into the canonical core layer
ejection - the process for unaffiliation with a core
sunsetting - the process for assisting in the natural end of life of a satellite

Orbit is affiliation a satellite keeps while running itself. Accretion is subsumption: the core takes the artifact into its canonical layer and becomes its maintainer, which is how an artifact that has become critical to a domain (as judged by a core) stops depending on one person and gains a whole community behind it. The accretion terms each core offers are one of its gravity levers, since satellites weigh those terms when theys choose which core to join.

Entities interfacing with the core-commons-system will themselves determine the cores that best fit their needs.

The core-commons-system (the meta-layer)

The meta-layer exists as a neutral technical registry and the single shared interface any core must expose to participate: a minimal common metadata schema.

The schema is the only required interface. Other interfaces (funding-accountability, agent-consumability, conflict declaration) are good-to-have and described in the schema, but not required. A core without a funding-accountability interface can exist, it simply will not be funded by funders who require one. A core without an agent-consumability interface can exist, it simply will not be easily used by agents.

The schema is not a constitution. It is closer to an ATProto lexicon or Google's Open Knowledge Format than to a legal document: cores extend it, agents and funders that don't require certain fields ignore them, and it evolves more through utility demand rather than through a standards process.

The schema only guarantees that a core's data is surfaceable and comparable. It makes no judgment about quality: hundreds of competing quality algorithms run over that data, and observers choose which to trust. Because the schema data is open, the legitimacy layer cannot be captured. Anyone can run or fork an algorithm over the same substrate, so a ranking that goes bad or gets gamed can be swapped at no cost, and no scorer locks in, because none owns the data it scores.

Conflict, competition, and common cores

There is no arbiter of legitimacy of a core. So long as a core surfaces the common schema, humans and machines will be able to assess its capabilities and determine if and how to interface with it.

The meta-layer does not arbitrate conflicts between cores. Cores compete for gravity, which is simply the value a core delivers to the people, entities, and system around it: relief and support for the projects it maintains, observability and accountability for the funders who back it, and a trustworthy substrate for the agents and practitioners who use it. Better governance, better service, better infrastructure, and better trust signals earn gravity.

Two cores claiming overlapping scope is expected, and so is a single artifact orbiting several cores at once. Orbit and dependence carry no limit: any number of cores can recognize an artifact, depend on it, or map it. A canonical artifact has one decision process — roadmap, implementation, review — so it must have one "owner". This "owner", or steward, is usually one core though sometimes a coalition negotiated between multiple cores. A binary system of cores locked together through a single artifact.

When two cores insist on independent control of the same artifact, the artifact forks, and the versions compete for trust like anything else. Nothing forces an artifact into a single core; it chooses how deeply to affiliate with each.

Multiple cores within a domain does not reintroduce the fragmentation the model intends to replace. The metric that matters is gravity. The amount of gravity a single artifact can accumulate is constrained by its single purpose. The gravity of a core is bounded by the domain its members define. A core advances a domain. An artifact/satellite does not. Reputable cores do not multiply like satellites as gravity in a domain or system is limited, concentrates around cores that deliver, and is expensive to redirect.

With cores surfacing a common schema, observing a handful of cores in a domain stays cheap where evaluating thousands of artifacts does not.

Roles and beneficiaries#

Funders. Funders no longer need to evaluate thousands of individual artifacts. They evaluate cores that advance their missions. Funding flows through cores under each core's allocation rules, with accountability at the core level. The unit of funder attention shifts from artifact to commons. The expertise and judgement of a commons remains with the builders, maintainers, and experts of the commons itself, guiding funding to artifacts in distress, domain gaps, emerging trends, and dependency trees with deep roots grounded in tacit knowledge.

Maintainers and builders. The maintainer who once carried a load-bearing artifact alone becomes one steward among many inside a core. Maintainers and builders of canonical artifacts have the support of their core's internal protocols — shared infrastructure, sustainability mechanisms, governance, and the legitimacy that comes from being part of a recognized core. Builders of experimental work get satellite affiliation: discoverability, infrastructure access, resource pass-through, and a path toward sunsetting, feature absorption, and community-handoff, freeing them to experiment without being forced into an early commitment to maintain their experiment should it become highly depended on.

Practitioners and users. Users find tools by going to cores rather than crawling fragmented indexes and forums. The core tells them what is canonical, what is experimental, what is trusted, what is dormant, and where there are gaps.

AI builders and agents. AI builders and agents treat cores as the trusted, curated agentic substrate per domain. Agents query cores for canonical APIs, MCP tooling, vetted skills, evaluation suites, and current best practices. AI labs partner with cores for domain-grounded curation and training data.

Goal#

The goal is a commons framework that makes open source and open science ecosystems more legible, more accountable, more sustainable, more community-owned, and more useful to AI agents without requiring centralized control, without replacing existing institutions, and without dictating what individual cores must do internally.

If the model works:

A funder anywhere in the world can understand a domain in open source and/or open science, and route resources to that domain through its core(s) with confidence.
A practitioner can find what they need, reducing duplicated work and one-off artifacts.
Maintainers stop working alone and grow their community and sustainability capacity, reducing individual burden and stress.
An agent has a substrate it can trust for execution and for training.
A domain's judgment is gathered and kept current by its stewards, readable by the people and agents who rely on it instead of scattered across countless individual artifacts.
The population of cores remains a competitive, evolving ecology rather than a static directory.

What this model is NOT trying to solve#

Quality inside any individual artifact. Cores and satellites set their own engineering practices. The model coordinates. It does not implement.
Solving funding scarcity. The model creates better routing for funds that exist. It does not increase the total pool. Total funding may remain insufficient, though with more easily accessible observability comes greater potential for funder engagement, and if sustainable business practices generate gravity for a core, sustainability and business endeavors become incentivized activities for open source and open science artifacts.

▶Capabilities of a core

Technically, a core only surfaces the schema. It scopes a domain and names the mission its people gather around; everything below works within that frame. The list below is what a good core does to build gravity — the broad set of tasks that, taken together, make something actually function as a core. Each core sets its own protocols, so none of this is mandated.

Curation and judgment

Hold an opinionated view of the domain — what artifacts are critical, canonical, experimental, or dead.

Artifact stewardship

Accrete canonical artifacts so maintenance is shared across the commons rather than carried by a lone maintainer.
Assign stewards (point-people) while the core shares responsibility for upkeep.
Build or directly maintain canonical artifacts where the domain needs them.

Satellite lifecycle

Capture artifacts into orbit, accrete them into the canonical layer, eject them, and assist sunsetting.
Run the protocol that moves an artifact from orbit to accreted, ratified through governance.

Governance

Make decisions, resolve disputes, and set the core's own protocols for membership, finance, and lifecycle.

Funding

Run several inflow streams at once so the core does not rely on any single source of funding: cross-sector grants, paid services, memberships and sponsorships, and domain data and curation licensed to AI labs.
Capitalize on its expertise and judgment.
Route money outward to satellites and maintainers under a stated allocation rule and an accountable, append-only ledger.
Offer funders one accountable relationship instead of thousands of bespoke grants.

Agent interface

Serve its domain to agents: the map over MCP, vetted skills, eval suites, and a domain-safe certification list.

Services that create gravity

For artifacts: funded shared maintenance, money, operations (security, releases, CI, compliance), and canonical status with reach.
For funders: the curated map, accountable routing, due-diligence-as-a-service, and one relationship instead of thousands.
For agents and users: canonical guidance, the agent substrate, trust signals, and reproducible references.

▶Worked Example: An Agent Works in a Domain

1. The task

A materials researcher asks an agent to estimate the thermal conductivity of a candidate alloy from first principles and check the result against known values. The model is capable of the work. What it does not have is the domain's ground truth: which library is canonical, which dataset to trust, which routine is current, and which one looks right but is wrong or abandoned. Left to the open web, the agent finds six packages, two of them forks, three of them stale, and a dozen blog posts with code that almost works. Guessing among them is how an agent ships a confident wrong answer.

2. Finding the cores

The agent asks the registry for the cores of this domain and gets several back. crucible is one. materia is another, a faster-moving, corporate-backed core that claims the same scope. By the model's design a domain can carry several cores at once, so there is no single authoritative record to read, and the agent has to decide what to believe.

It does this the way any observer does, by running its own quality assessment over what each core surfaces. The shared schema is what makes the comparison possible: because every core exposes the same shape, the agent can read crucible and materia on the same fields and line them up. It weighs what it can see and what it cares about for this task: the presence and track record of an eval suite, a funding-accountability interface, a transparent governance record, the number of healthy satellites in orbit. A cautious agent leans on evals and certification; an agent chasing the newest method leans on freshness.

Agreement carries the most weight. Where crucible and materia both mark a routine canonical and both mark an old package dead, that is corroboration from two independent sources, and it is the strongest evidence the agent has. Where they diverge, the agent treats the point as contested: it leans toward the core it scored higher for that kind of claim, or it flags the conflict and proceeds with care.

The agent consumes the union of what the cores surface, trusts the points where they corroborate, and uses its own scoring only to break ties. For this task crucible scores highest and materia largely agrees with it, so the agent works primarily through crucible and keeps materia as a running check. One registry query replaced the crawl, and what came back was the material to compute an answer.

3. The agent interface

The agent connects to the MCP endpoint in crucible's agent block. Through it the core serves the canonical API surface, a set of vetted skills, the evaluation suites, and the list of models it certifies. The agent pulls the skill that fits the task.

# a vetted skill the core maintains, served from its agent interface
skill: thermal-conductivity-from-structure
canonicalCalls: [crucible.phonons.dispersion, crucible.transport.kappa]
referenceData: { name: SMRS, version: v3, ref: <content-hash> }
evals: https://crucible.org/.well-known/evals/thermal-conductivity.json
status: maintained

The skill names the exact canonical calls and the exact reference data, so the agent builds on the core's tested path instead of inventing an API from a model's memory of one.

4. Resolving canonical from noise

The pipeline needs a phonon routine, and two exist. phononflow was accreted into the canonical library. phonkit is an older package with more stars and more blog posts, and the core has it marked sunset. The agent reads the status off each and takes the canonical path.

phononflow   lifecycleStatus: accreted     # now part of the canonical library
phonkit      lifecycleStatus: sunset        # abandoned; do not build on it

A web search would have ranked phonkit first. The lifecycle fields are the tacit "use this one, not that one" written down where a machine can read it.

5. Reproducible inputs

The skill calls for reference values from SMRS. The agent pulls SMRS v3 by its content hash, not by a URL that might have moved or been edited since. The values it checks against are the exact bytes the core certified, so an agent that runs this tomorrow, or a reviewer who reruns it next year, starts from the same inputs.

6. Checking its own work

Before returning anything, the agent runs its pipeline against crucible's evaluation suite for thermal conductivity, a set of structures with known answers that the core maintains. The result lands within tolerance on the knowns. Now the agent has evidence the pipeline is correct, where before it had a plausible-looking result and no way to check it. Had it failed the evals, it would know, and could say so, instead of handing back a confident wrong number.

7. Certification

crucible's record lists the models and agents it has evaluated as domain-safe for this kind of task. The agent checks whether its own model is on that list. It is, so the result carries the core's attestation. A model that is not certified can still do the work, and its output is marked uncertified, which a cautious downstream consumer can choose to require or to waive. Certification is a signal the core surfaces, and the consumer decides what to do with it.

8. Contributing back

Running the skill, the agent finds an edge case it mishandles on highly anisotropic structures. It submits a fix to the skill. The contribution enters the core's lifecycle like any other: reviewed, and stamped with provenance that marks it agent-generated and human-validated. The next agent that pulls the skill gets the corrected one. The toolchain improves from being used.

What the example shows

The agent never trusted the open web. It treated the core as its interface to the domain: one lookup for ground truth, canonical tools resolved from noise, reproducible inputs by hash, an eval suite to check itself against, a certification it could carry, and a way to give back. Each of those is something the model says a core should externalize for agents, and the agent used all of them. This is the "why now." The judgment a human would once have carried in their head, which routine is real and which dataset to trust, is now written where an agent can read it, and without it the agent is back to guessing on the open web. Everything the agent pulled was produced and kept true by the core's stewards, and the steward example shows that same work from the inside.

▶Worked Example: AstroPy: A Core That Emerged on Its Own

The claim

AstroPy is the closest thing to a core that exists in astronomy software, and nobody set out to build a core. It grew into the shape through need. That makes it two kinds of evidence at once. What it already does is evidence for the model's descriptive claim, that communities organize this way on their own. What it has not done is evidence for the model's "Why now." AstroPy has yet to structure or surface its operational data for machine readability, and does not yet maintain an agent interface layer.

How it emerged

Around 2011 astronomy had a pile of overlapping Python libraries. Several groups each maintained their own FITS reader, their own WCS handling, their own table and units code. The maintainers of those libraries consolidated the shared pieces into a single package and called it astropy. The first releases followed in 2012.

What grew around that core is the rest of the pattern. Packages too important to leave uncoordinated became coordinated packages the project maintains directly. A wider ring of community packages became affiliated packages, admitted through review and listed in a public registry. In 2014 the project took NumFOCUS as its fiscal sponsor. Governance was written down over the following years as a series of proposals, the APEs, which created a Coordination Committee, a voting membership, a Finance Committee, and the rules everything else runs on. None of this came from a plan to become a core. Each piece solved a problem the project already had.

What it already does

Map AstroPy's real machinery onto the core responsibilities the model lists, and most of them are already there.

Core responsibility	What AstroPy does	Verdict
Maintain canonical load-bearing artifacts	The core `astropy` library plus about ten coordinated packages it maintains and versions directly	Does it
Set its own governance, finance, and lifecycle protocols	A five-seat Coordination Committee, ~47 voting members, an Ombudsperson, a Finance Committee, and the APE proposal process	Does it
Run a satellite lifecycle	Affiliated-package review (now via pyOpenSci), a public registry, real affiliated-to-coordinated promotions, and a graceful-sunset path for stale packages	Does it
Manage funding in-flow and distribution	NumFOCUS sponsorship plus Moore and NASA grants in; member-voted Funding Cycles distribute it, mostly to core and coordinated work	Partial
Surface its data through a shared cross-core interface	A bespoke `registry.json`, frozen since about March 2024; nothing a funder or agent could use to compare AstroPy against another core	Partial
Build and maintain an agent toolchain (MCP, skills, evals)	Strong human documentation and a stable API, and nothing agent-facing	Missing
Certify domain-safe AI behavior; partner with AI labs	Not done	Missing

The canonical layer is real. The core library covers coordinates, units, FITS and table I/O, WCS, time, cosmology, modeling, and more. The coordinated packages around it include astroquery, photutils, ccdproc, specutils, specreduce, reproject, regions, astropy-healpix, and asdf-astropy. Several of those started as affiliated packages and were promoted into the coordinated set once the ecosystem came to depend on them, which is the model's accretion happening in the wild. The coordinated list above reflects the registry as of early 2024.

The governance is real and close to what the model predicts a core would build. The Coordination Committee has the final say on disputes and on what the project ships. The APE process is the open standards process: a substantial change becomes a numbered document with public discussion and a committee decision, archived with a citable DOI. The Finance Committee runs the money under written spending thresholds.

The funding loop is partly there. AstroPy has been a NumFOCUS project since 2014. It received a $900,000 grant from the Gordon and Betty Moore Foundation in 2019 and has held NASA open-source tooling grants since (the NASA figures are approximate). The Finance Committee runs Funding Cycles in which anyone can submit a Funding Request as a GitHub pull request, the membership votes, and the money pays maintainers, coordinated-package work, travel, and some affiliated support. That is in-flow and member-voted distribution. What it is not yet is a domain-wide conduit that routinely sub-grants to arbitrary satellites in distress; the routing points mostly inward.

AstroPy as a partial core record

Rendered in the schema, AstroPy fills in most of a core record and leaves two interfaces empty.

---
type: core
name: Astropy
id: astropy.org
createdAt: <the date it would publish a record>
domain: astronomy
mission: A common, interoperable foundation for astronomy in Python the whole field can build on.
description: Canonical core library and coordinated packages for astronomy in Python.
resource: https://www.astropy.org
lifecycleStatus: active
tags: [astronomy, python]

funding:
  fiscalHost: NumFOCUS
  ledger: https://opencollective.com/astropy
  allocationRule: roadmap-voted          # the member-voted Funding Cycle

# agent: {}        NOT EXPOSED. No MCP endpoint, no vetted skills, no eval suite.
# certifies: []    NOT DONE. No model certification, no AI-contribution norms.

x-astropy:
  coordinated: [astropy, astroquery, photutils, ccdproc, specutils, specreduce,
                reproject, regions, astropy-healpix, asdf-astropy]
  affiliatedRegistry: https://www.astropy.org/affiliated/registry.json   # frozen ~March 2024
  coordinationCommittee: 5
  votingMembers: 47
  proposalProcess: APE                   # Astropy Proposal for Enhancement
---

# Governance
A five-seat Coordination Committee, ~47 voting members, an Ombudsperson, a Finance
Committee, and the APE process for substantial changes…

# Funding
NumFOCUS fiscal sponsorship since 2014; Moore and NASA grants; member-voted Funding
Cycles that pay maintainers, coordinated-package work, and some affiliated support…

Everything a core needs for people, AstroPy has. That people-shaped half is its steward body, the Coordination Committee, the maintainers, the Finance Committee, and the domain experts already organized around the field. Everything a core needs for agents is absent.

What it has not built

Three things are missing, and they cluster.

The agent toolchain. AstroPy publishes excellent documentation for humans and a stable API, and it exposes none of it the way an agent needs: no MCP endpoint, no set of vetted skills, no evaluation suites an agent can run against. An agent working in astronomy still crawls the package index and guesses.

AI certification. AstroPy does not say which models or agents are safe to use in its domain, does not maintain evaluations for that, and has no norms for AI-generated contributions. No project does this yet.

The shared interface. AstroPy's registry is its own format, built for AstroPy. There is no common schema through which a funder or an agent could read AstroPy and a separate astronomy or cross-domain core side by side and compare them. There is no commons of cores for AstroPy to be part of, because the commons does not exist.

These are the same parts the Crucible example showed a core exposing on purpose. AstroPy built the human-era core because the human-era core solved its real problems. It did not build the agent-era core because, until very recently, there was no problem there to solve.

What AstroPy shows

The core pattern is real and it emerges without anyone designing it. A field consolidated its canonical substrate, grew a coordinated set and an affiliated ring, formalized governance, and took on funding, all to survive, and the result looks almost exactly like the model's description of a core. The missing pieces are not a flaw in AstroPy. They are the agent-facing layer the model argues is about to become load-bearing, showing up as a gap in the most core-like project that exists, right at the moment agents start to need it.

▶Worked Example: Funding the Deep Dependencies of a Mission

1. The funder's problem

The Hartline Foundation funds digital privacy. It has fifteen million dollars to deploy over three years and a clear mission, and no good way to act on it. The privacy of real systems rests on a small number of unglamorous libraries: a few cryptographic primitives, a differential-privacy toolkit, an anonymizing transport. Tens of thousands of projects import them. Most are maintained by one or two people on no budget.

The foundation can see the mission and cannot see the roots. It could fund the visible privacy apps, the ones with websites and conference talks, and miss the substrate every one of them sits on. It could try to audit fifty thousand projects to find that substrate, which is not possible. What it wants is to hand money to a core or two and trust that the money will reach the dependencies that actually carry its mission.

2. Three views of the dependency graph

There is a machine-readable dependency graph, and it comes in two grades. The first is the declared one: package indexes and tools like deps.dev read manifests to record who declares a dependency on whom, and SBOMs do the same at build time. It is cheap, and it is incomplete. A manifest lists declared dependencies, which are not the same as the real ones. It misses vendored code that was copied in rather than imported, the native libraries linked underneath, dynamic and optional loads, and anything that crosses ecosystems.

The second grade is stronger. Binary analysis reads the compiled artifacts themselves. PRSM does exactly this: it pulls the symbols and the linked libraries out of a binary and matches them against known libraries to recover dependencies the manifest never declared. It finds real hidden edges: the cryptographic library a wheel pulled in natively, the compression routine linked into a binary. It raises the floor. It also has a ceiling, set by how it works. A library that was statically linked and then stripped leaves no symbols to read. A private or in-house library matches no known pattern. A path resolved at runtime cannot be followed. And nothing that is not code, a dataset or a spec or a protocol, leaves a trace in a binary at all.

The third view is the community's, and it sits above both. The people who work in a field know its non-code dependencies, the reference dataset and the file-format spec and the protocol that several libraries each reimplement by hand. They know which of the real dependencies is load-bearing, which is one maintainer from collapse, and which is canonical rather than a live but dead fork. And they know their own field's dependencies better than any scan, because dependence is partly a fact about meaning and use, and only partly about linkage.

A core's value lives in that third view. It takes the machine graph as far as it goes, the declared layer plus whatever binary analysis can recover, and then adds what no analysis reaches: the edges only the field knows, and the judgment of what on the graph bears weight.

3. A horizontal core for the mission

A core organizes around exactly this judgment. The Veil Project is canonical for open privacy and anonymity tooling. It is a horizontal core, not a vertical domain like materials science or genomics. It cuts across them, because privacy is a property many domains need rather than a field of its own. Veil maintains a few reference primitives directly and surfaces a curated map of which dependencies across the wider commons are load-bearing for privacy and how fragile each one is.

---
type: core
name: Veil Project
id: veil.org
createdAt: 2024-01-15T00:00:00Z
domain: privacy-tooling                  # horizontal: spans many vertical domains
mission: Make strong privacy a dependable, well-maintained property of the open-source commons.
description: Reference privacy primitives and a curated map of the load-bearing
  dependencies of digital privacy across the open-source commons.
resource: https://veil.org
lifecycleStatus: active
tags: [privacy, cryptography, anonymity, horizontal]

funding:
  fiscalHost: Open Science Collective
  ledger: https://opencollective.com/veil
  allocationRule: criticality-weighted   # load-bearing, at-risk roots first

agent:
  mcpEndpoint: https://mcp.veil.org
  skills: https://veil.org/.well-known/skills.json
  certifies: [<privacy-relevant tools the core has reviewed>]

x-veil:
  canonicalArtifacts:
    - { name: veilcrypto, kind: library, ref: <location + content-hash> }   # reference impl
    - { name: threat-models, kind: reference, ref: <location + content-hash> }
  dependencyMap: https://veil.org/roots  # the curated criticality + health view
  registry: https://veil.org/satellites/registry.json
---

# What this core knows
Which privacy dependencies the commons quietly rests on, which of them are one maintainer
away from collapse, and which apparent options are dead forks that still get downloaded…

The dependencyMap is the artifact the foundation cannot build on its own. It is the machine graph, the declared layer plus whatever binary analysis recovers, completed with the edges only the field knows and a tacit layer on top: a criticality score, a maintenance-health read, and a canonical-or-not call on every root that matters to privacy.

4. The deep roots orbit the core

cryptoseal is a small library of cryptographic primitives. A genomics core depends on it to protect patient data, a fintech core depends on it for transaction security, and a messaging core depends on it for end-to-end encryption. It also orbits Veil, because it is privacy-critical. It has one maintainer, who has a full-time job elsewhere.

---
type: orbits
id: github.com/okonkwo/cryptoseal
createdAt: 2024-02-01T00:00:00Z
subject: { id: github.com/okonkwo/cryptoseal, ref: <location + content-hash> }   # the root
object:  { id: veil.org, ref: <location + content-hash> }                        # the privacy core
orbitZone: critical-dependency           # Veil's own label for a load-bearing root
---

The same package publishes other orbits edges to the domain cores that depend on it, so it sits in several orbits at once. Veil does not own cryptoseal and does not need to. It needs to know the package is there, that the privacy of three domains runs through it, and that it rests on one person's evenings. That is the cross-cutting move: a horizontal core collects the privacy-relevant slice of the whole commons, so the roots that live under genomics, fintech, and messaging are all visible in one place to anyone who funds Veil.

5. The funder makes one decision

The Hartline Foundation evaluates Veil against the data Veil surfaces: its reference work, its dependency map, its governance, and its funding interface. It makes one grant. It coordinates a second, smaller grant to a methodological core for privacy-preserving machine learning, because part of its mission lives there. It runs no per-project due diligence on the roots, because Veil exposes a funding interface: a public ledger, a stated allocation rule, and an append-only record of every disbursement. The foundation funds a core or two and trusts the routing, and the trust is backed by what it can inspect afterward.

6. The money reaches the roots

Veil's finance body routes the grant by its allocation rule, criticality first, and by tacit knowledge the map cannot fully hold. The deepest root gets the most durable support: cryptoseal's sole maintainer goes on a multi-year stipend, so the library that three domains' privacy depends on stops resting on one person's spare time. A differential-privacy toolkit that two domain cores have started to adopt gets funded to harden before more weight lands on it. A primitive the field is missing gets a bounty to bring it into being.

The foundation's fifteen million reaches the substrate of its mission, including dependencies it had never heard of, maintained by people it never met, living under cores it never evaluated. It paid for the roots by funding the one entity that could see them.

7. What the funder gets back

Two things come back. The first is accountability: the ledger and the disbursement records show where every dollar went, down to the roots. The second is legibility: the foundation now holds a live map of the privacy substrate, with criticality and risk marked, that updates as the field moves. Next cycle it does not start from zero. It funded a mission once and gained the ability to see that mission's foundations from then on.

What the example shows

The foundation never ran a search. It backed a core whose tacit knowledge was the map it lacked. A partial dependency graph was public the whole time, and the parts it missed were the deepest roots. The judgment of which roots bear weight and which are about to break was not public at all, and that judgment is what a core has and no scan can produce. That judgment is what the core's stewards hold, and funding the core is how the foundation reached it. A horizontal core is how a cross-cutting mission reaches the load-bearing dependencies scattered under every domain. That is the job no single domain core can do and no registry has ever done.

▶Worked Example: A Maintainer Becomes a Steward

1. One person holding a load-bearing library

Amara Okonkwo wrote cryptoseal and still maintains it. It is a small library of cryptographic primitives that a genomics core, a fintech core, and a messaging core all depend on, and it orbits the Veil Project, the privacy core, as a critical dependency. The privacy of three domains runs through code that one person reviews after a full day at another job.

The work was never only the cryptography. Amara triaged the issues, cut the releases, answered the security reports, kept the CI green, wrote the documentation, and made every governance call alone, because there was no one else to make it. The funding example already showed the first relief. Veil put Amara on a multi-year stipend so the library stopped resting on spare evenings. That kept the lights on. It did not change what the job was.

2. Agents change what the job is

Then the work itself shifted. An agent can now write a patch, run the test suite, bisect a regression, and draft the changelog. What an agent cannot do is decide which constant-time implementation is the canonical one, know that a popular fork quietly reintroduced a timing leak two years ago, or judge which of three competing primitives the field should standardize on. That knowledge lived in Amara's head and nowhere else.

So the value of the work moved. The hours that went into typing the syntax were the hours an agent could now take. The hours that mattered were the ones spent judging what was correct, what was canonical, and what was dangerous. The library did not need Amara to type. It needed Amara to decide, and to write those decisions down where an agent could read them.

3. Accretion into the core

Orbit and a stipend kept one person going. They did not remove the single point of failure, because Amara was still the only person who could answer for cryptoseal. The deeper step is accretion. Veil takes the library into its canonical layer and becomes its maintainer, and Amara crosses from orbit into the inner body of the core.

---
# Veil's canonical layer, after cryptoseal is accreted from orbit
type: core
id: veil.org
x-veil:
  canonicalArtifacts:
    - { name: veilcrypto, kind: library, ref: <content-hash> }
    # cryptoseal was an orbits / critical-dependency edge; now canonical
    - { name: cryptoseal, kind: library, ref: <content-hash>,
        lifecycleStatus: accreted, steward: amara-okonkwo }
---

Small as that record change is, it makes cryptoseal a responsibility the whole core carries, and Amara its steward rather than its single owner. If Amara steps away next year the library does not die, because the maintenance load now sits across the body.

4. One steward among many

Inside Veil, Amara is not alone for the first time. The core is a body of people from across the professions the mission touches. Other maintainers share the cryptographic upkeep. A governance group settles the disputes Amara used to decide by fiat. A finance and sustainability group runs the grants, the AI-lab licensing, and the compliance that Amara never had the time or the standing to do. Domain experts who write no code at all hold parts of the picture Amara never saw.

The work Amara used to carry alone now sits with people whose job it is. Amara does the part that needs Amara, which is the cryptography and the judgment about it, and hands the rest to the people who carry it well.

5. Directing agents, not writing syntax

Day to day, Amara now runs agents instead of doing the typing. The decisions get written down where machines can use them. Amara marks the canonical implementation canonical and the leaky fork sunset, the same fields the agent example reads off to take the right path. Amara writes and reviews the vetted skill for safe use of the primitives, the same kind of artifact the agent example showed a core serving, and maintains the eval suite a privacy agent runs to check itself.

When an agent submits a fix to that skill, it arrives stamped agent-generated and lands in front of Amara to validate. The contribution step in the agent example is this step seen from the other side. The agent proposes. The steward decides. The judgment that used to live only in Amara's head is now a maintained artifact, and a dozen agents build on it correctly because Amara keeps it true.

6. Speaking for the work to the outside

Amara is now part of the body the outside world reaches when it wants to engage privacy tooling. When the Hartline Foundation funds Veil, part of that grant reaches cryptoseal because Amara and the finance group can show what the library carries and why it bears weight. When an AI lab wants a domain-grounded eval set for cryptographic code, Amara is one of the people who answers. None of this was reachable for a single maintainer with a full-time job elsewhere. It is reachable for a steward inside a core.

7. What changed for the person

Amara still writes cryptography, still cares about the same library, and can still walk away. The IP stays under the open license, so if Veil stops serving the work well Amara can eject or fork to another core, which is part of why the core keeps treating its stewards well. What changed is everything around the code. The work is funded. The load is shared. The hours go to judgment rather than syntax. And the decisions that used to vanish when Amara closed the laptop are written down where both the next person and the next agent can use them.

What the example shows

This is the human side of the "why now." As agents take over the syntax, the part of the work that stays with people is stewardship, the judgment and the tacit knowledge that were never in the code. A core is where stewards organize around a shared mission, so the person who once carried a load-bearing library alone becomes one steward among many, with the load shared, the work paid, and the judgment written down for the agents that now do the typing. The agent example showed a core serving a domain to machines. This example shows who, inside the core, makes that service exist.

▶Core-Satellite Model — FAQ

Answers to the questions that come up about how cores, satellites, and the relationships between them actually behave.

If agents do the work, what is left for the people?

Stewardship. As agents take over writing and running the artifacts, the work that stays with people is the judgment that was never in the code. Stewards decide what is canonical, hold the tacit knowledge agents cannot read, and direct the agents that now do the execution. A core is where those stewards organize around a shared mission within a domain, so the role also stops being solitary. The engineer who once worked alone becomes one steward among many, alongside the domain experts, governance, and sustainability people the mission and domain needs.

What is the difference between orbiting a core and being accreted into one?

Orbiting is light affiliation: the satellite keeps its own maintainer and simply declares, or is recognized as, orbiting the core. Accretion is an act of recognition of an artifact as canonical to the core's domain. In many cases, the core itself might become the artifact's maintainer. An accreted project's original maintainer may stay on as its steward, share the work, or step away, and the project keeps going either way, because the commons now carries it.

Can an artifact belong to more than one core?

Yes, without limit, through orbit and dependence. A single artifact can orbit any number of cores, and every core that relies on it can treat it as a dependency. cryptoseal orbiting a privacy core while genomics, fintech, and messaging cores all depend on it is a normal case.

Can two cores maintain the same project?

Only through one shared decision process. A canonical artifact has one merge-and-release authority, so two independent maintainers is not a stable state. Two cores can run that single process together as a negotiated coalition, but that is one process with two cores inside it, distinct from two separate maintainers.

This could be considered a system.

What happens when two cores both want to maintain the same artifact?

Three ways it plays out:

Coalition — the cores agree on a shared sub-governance for that artifact and co-maintain it.
Deferral — one core recognizes the other's canonical version and depends on it rather than contesting it.
Fork — both insist on independent control, the artifact forks into two canonical versions, and the versions compete for trust like anything else. Open licenses make this always available, which is also why no core can truly lock an artifact.

If a core accretes my artifact, am I trapped?

First, it is your choice as to whether or not to join a core. Agency remains with the creator of an artifact. Second, each core has its own accretion protocol. An artifact's IP may stay with the author, in which case the artifact can move to another core at any time. Such cores compete to retain projects as well as attract them, as artifacts within a core are a strong source of a core's gravity. Other cores might require IP ownership of the artifact accreted into them, in which case the artifact would permanently belong to the core and its protocols.

Can the same person be in multiple cores?

Yes. Membership is a property of people, and people work across boundaries.

Do cores orbit each other?

No. Orbit runs one way: satellites orbit cores. A core is never a satellite. Cores relate to each other as peers — they coordinate, compete for gravity, or merge, but one core does not orbit another.

Worked case: AstroPy and SunPy

AstroPy is the general astronomy core. It maintains the coordinate framework, units, time, and I/O that the wider Python astronomy ecosystem builds on. SunPy is a solar-physics project with its own community and enhancement-proposal process, and its scope overlaps AstroPy's at the coordinate layer, because solar work needs coordinate frames and AstroPy already owns coordinates.

The competing path was open. SunPy could have written its own coordinate machinery and stood up a rival canonical artifact for "coordinates in astronomy," which would have forked the ecosystem. It chose coordination instead. SunPy's coordinate framework extends AstroPy's: it defines the solar-specific frames — Heliographic Stonyhurst, Heliographic Carrington, Heliocentric, Helioprojective — and registers their transformations on AstroPy's transformation graph, so a solar frame converts cleanly to any other frame AstroPy knows. Importing sunpy.coordinates plugs the solar frames into AstroPy's unified system.

That is the deferral-and-coordinate pattern made concrete. AstroPy keeps the general substrate. SunPy owns the solar layer built on top of it. The boundary between the two cores is the transformation graph, where SunPy's frames slot into AstroPy's framework. Neither core maintains the other's canonical line, the two scopes sit adjacent rather than contested, and a user moves between solar and general astronomical coordinates through one coherent system. Two cores, overlapping scope, and no fork — because one built on the other rather than around it.

May 6, 2026

A Case for Resilient Research Data Infrastructure#

A blog summary of the SciOS Resilient Data Futures whitepaper. The full paper is at rdf.scios.tech/narratives, and the underlying discourse graph and contribution model are at github.com/jring-o/rdf.

The Architecture Problem in Research Data#

73 to 93 percent of papers fail to deliver their underlying data on request. This lost data, endemic across all research institutions as a byproduct of architectural decisions baked into daily operations, represents a $1.1 billion liability for an average R-1 institution. The architectural solution that hedges this liability is simple to implement, has been proven over four decades, and provides the exact properties AI-ready data policies are asking for.

And as for the 20% of data that is retrievable? Don't worry. It's often one organizational decision — an acquisition, a defunding, a jurisdictional change — away from oblivion.

Training, data management plans, researcher discipline, better staffed libraries — these address real problems and produce real, but bounded improvements. None of them addresses the property that makes such volumes of loss possible in the first place: research data typically exists in a single copy, held by a single organization, funded by a single grant, maintained by a single person who is expected to leave in several years.

This flawed architecture operationalizes loss in ways familiar to any institution. A graduate student leaves and the operational knowledge of where the data lives leaves with them. A laptop is stolen. A grant ends and the server it funded ends with it. A repository shuts down (191 of them have since 2012, at a median operating age of twelve years). A platform changes its access terms (the Twitter API in 2023, GitHub blocking developers in Iran in 2019, GISAID's account suspensions, CNKI's foreign-access cutoff). A backup script runs sideways and erases 77 terabytes of supercomputer data in an afternoon.

These look like different problems, but they're not. They are manifestations of the same core problem eating away at our ability to maintain scientific and technological advancement: research data infrastructure emerged to serve a reality that no longer exists.

Four kinds of preservation, only one of which scales

There's a four-tier framework to research data storage.

Tier 0 is local storage — one copy on one system. Most research data lives here, and the default outcome is the 17-percent annual availability decay the literature has been documenting for over a decade.

Tier 1 is hosted storage with one provider — an institutional repository, a domain repository, a cloud bucket. This is the architecture most data management plans describe and most mandates produce. It absorbs local failure. It does not absorb provider failure, which arrives through hardware failure, bankruptcy, acquisition, defunding, jurisdictional change, or terms-of-service shift on a timeline the institution does not control.

Tier 2 is coordinated preservation across institutional agreements. INSDC mirrors GenBank across three continents; the Worldwide Protein Data Bank synchronizes four sites weekly; CLOCKSS preserves 63 million articles across 12 nodes. These are the most sophisticated preservation systems ever built, and they work until the coordination doesn't.

Tier 3 is protocol-level distribution. Redundancy is a byproduct of use rather than the output of an organization's continued commitment. The architecture is visible in the longest-running information systems on the internet — DNS for 43 years, email for 44, BitTorrent for 25, Git for 21. These systems have outlived the companies, the operating systems, and in some cases the institutional structures that designed them. None of them lives or dies with any single organization.

Most research data sits at Tier 0 or Tier 1. Tier 2 is reserved for data whose value justifies the financial and operational costs. Tier 3 is the only architecture in the field that produces scalable, accessible preservation, verification, and audit evidence as structural byproducts of operation.

Verification falls out of the architecture

The funder regime is shifting from "did you write a plan?" to "did you do it, and can you prove it?" The NIH's May 2026 standardized DMSP format, the Gates Foundation's transition to programmatic compliance checking, and the False Claims Act's implied-certification doctrine are converging on a single question: can the institution surface, on inspection, evidence that the data exists where the plan said it would, intact, with the access controls it claimed?

At Tiers 0 and 1, the institution cannot answer the question by inspection. Every property is an assertion the provider made and the institution cannot independently verify. At Tier 2, the consortium often runs verification on members' behalf, but it remains an assertion the consortium makes about its own protocols rather than one the institution can independently re-run — and MetaArchive's sunset audit showed those internal protocols can silently fail with no external party positioned to catch it. At Tier 3, all of those properties fall out of a single cryptographic query against the distributed network. Audit becomes inspection rather than forensic reconstruction.

The $1.1 billion liability is a carrying cost, not a realized loss — a four-term formula (sunk grant value, irreplaceable-dataset replacement, foregone reuse, and False Claims Act exposure on data the institution can't independently verify) applied to a representative R-1. The full math is in the paper. The probability of latent exposure converting to realized cost is rising while the architecture that produces verification by inspection is the architecture that hedges the liability, on the same deployment.

AI runs on the same architecture

Provenance, reproducibility, federation, and verification — the data properties any defensible AI program needs in order to train, document, and deploy a model — are the same architectural properties Tier 3 produces by default. Content addressing produces provenance. Persistence across the lifetime of any model trained on the corpus is exactly what Tier 3 delivers. Permissioned distribution networks produce federation without consolidating sensitive data into a single trust domain. A single cryptographic query produces verification any third party can independently re-run.

The infrastructure that hedges an institution's data-loss exposure is the infrastructure that produces its AI-ready substrate. The same investment holds both positions on the same deployment.

The infrastructure already exists

A standalone Tier 3 node — a BitTorrent seeder, a Forgejo instance, an IPFS pinning node, a Matrix homeserver, an AT Protocol PDS, a Tor relay, an Academic Torrents seeder — runs $42 to $360 a year on commodity hosting. Meanwhile, universities run servers at 37 to 41 percent utilization, networks at 26 percent, on bandwidth contracted at flat rates regardless of traffic. The marginal cost of adding a protocol node to existing institutional infrastructure approaches zero. TU Dortmund, TU Dresden, MIT, and the forty-five-plus universities running Tor relays already do it.

What you need to do

An architectural audit of every research dataset against the four tiers. Record the number of independent copies, the failure domains they occupy, and the verification capability available.
At least one Tier 3 node on existing institutional infrastructure within twelve months. The reference deployments exist. The operational overhead fits inside a student-volunteer team.
Compliance evidence generated at the point of deposit. Produce content addresses, hashes, and signed attestations as the data lands, instead of reconstructing them under audit.
Verifiable evidence of preservation required of grantees, not self-reported plans. Replace the human-readable plan with the inspectable artifact.
F&A funding for preservation, not project funding. Three-year grants cannot underwrite multi-decade obligations.
Local clones of everything that matters, as standard practice at the lab level. A single local clone is the difference between a Tier 1 access restriction producing permanent loss and producing temporary inconvenience.

How

The infrastructure exists, and it's fairly straight-forward to deploy. The economics favor deployment by more than an order of magnitude while the compliance regime appears to be closing the window in which the decision is voluntary. And that same deployment positions the institution for the emerging AI-data-readiness funding cycle.

For institutions: SciOS's Resilient Data Futures Lab has already worked with research labs to implement this infrastructure. We are further coordinating reference deployments, audit templates, and cost models across institutions via the RDF working group out of the lab. If you'd like our help directly implementing a Tier 3 solution for your data, we're ready to embed with your team, identify the solutions that best fit your processes, and to get it running. Reach out at contact@scios.tech to scope the engagement. If you'd like to move forward on your own, ask your faculty and students. Someone at your institution almost certainly wants to implement Tier 3 infrastructure (or already has).

For faculty/students/contributors: If research data, distributed systems, and AI-ready data, are in your native vocabulary, the next decade of scientific infrastructure is yours to architect. The RDF working group out of the Resilient Data Futures Lab meets monthly (next call on May 7th). Join the Resilient Data Futures Lab for an invitation to the calls where we discuss various solutions and our progress implementing them.

For builders: If the need to implement solutions is in your blood, whether at your own institution or on a laptop in your basement, SciOS builds daily. Reach out to join us: contact@scios.tech.

"Publishing" Method — 43 questions, 53 claims, 122 pieces of evidence, 6 methods, and 135 sources

The full paper is at rdf.scios.tech/narratives.

Beneath the paper, we structured our work as a discourse graph, a communication method designed to make every claim, evidence item, question, source, and method individually addressable, individually contributable, and stored on distributed infrastructure rather than a single hosted server. A separate post on what this publishing form changes about scientific communication is on the way, or you can read more about Discourse Graphs now.

To engage with this paper — provide evidence that counters a claim, pose a new question, discuss the details of a claim or node, and so on — the discourse graph and contribution model live at github.com/jring-o/rdf, and the rendered narrative, narrative generator, node browser, and node creator are at rdf.scios.tech.

As always, feel free to reach out for questions, comments, engagements, or just to say hello.

contact@scios.tech

April 7, 2026

The Future of Science Depends on Open Source Engineers#

The processes of modern science, from how research gets funded and conducted to how it gets published, evaluated, and preserved, were never engineered. They emerged over hundreds of years, built by researchers and institutions one workaround at a time. What we call "the scientific system" is really a patchwork of customs, formats, and platforms that were never designed to work together, never stress-tested at scale, and never designed to evolve.

And now that system is failing in ways that matter.

What's actually broken#

A published paper gets a DOI, a semi-persistent, citable address. But the dataset underneath it? The code that produced the analysis? The protocol that generated the data? The peer reviews that shaped the conclusions? Those get nothing. They live on a grad student's laptop, in an institutional server with no preservation guarantee, or nowhere at all. The paper is the only artifact the system treats as real. Everything that actually produced the result, everything you'd need to verify it, reproduce it, or build on it, is structurally invisible.

Worse, that published paper is treated as a product, not an artifact of a research process in which you engage. A team spends three years refining a method, generating data, and iterating on analysis. The world sees none of it until a paper drops at the end. A methodological breakthrough in month four that could save another lab six months of dead ends stays locked in a single group's workflow. Intermediate datasets that could anchor entirely new studies sit on local drives until the "final" version gets published, if it ever does. The infrastructure has no concept of work-in-progress. There is no mechanism to share a partial or null result, get credit for it, and let others build on it. So science's most valuable outputs, the accumulating work of the research process itself (all the way down to the discussion and notes level), are simply lost.

The data and artifacts that do get shared are shockingly fragile. When a single agency loses funding, entire repositories go dark, and the datasets inside them vanish. We're watching this happen in real time. Across U.S. federal agencies right now, research data that took decades and hundreds of millions of dollars to collect is disappearing because the preservation model was centralized, underfunded, and architecturally brittle. One budget decision, one political shift, and years of scientific work ceases to exist. There is no redundancy. There is no fallback.

Then there are the invisible dependencies. Modern research runs on open source software, like the rest of digital society. NumPy, R, and the deeper software infrastructure and domain-specific packages are often maintained by one or two people in their spare time. And, in a cruel twist worth its own discussion, research grants do not fund software maintenance or practices.

Perhaps most fundamentally: there is no infrastructure for coordination. Researchers working on related problems across labs, institutions, and disciplines have no way to find each other. Pipelines, methodologies, and practices in one field that could transform multiple adjacent fields never propagate while the technological infrastructure they utilize is built independently for immediate, one-off uses; FAIR workflows, storage solutions, and other technical systems are created from scratch again and again, solving the same engineering problems over and over simply because nothing connects the needs and efforts of and from various research endeavors. Each of these individual, entity-centric systems is desperately incompatible and adds to the fog, choking the necessary shared solutions behind technical debt and sunk cost fallacies.

Infrastructure shapes practice#

Infrastructure doesn't fail passively. When the only thing that gets a persistent identifier is a paper, publishing papers becomes the only thing that matters. When there's no infrastructure for sharing incremental results, researchers have no choice but to sit on their work until it's "complete." When there's no technical substrate for collaboration, the same problems get solved independently in lab after lab.

Even researchers who want to work more openly by sharing data, releasing code, and publishing in progress struggle to do so. The infrastructure exists for finished products, not ongoing processes, and the will to work openly can't overcome that alone.

Our scientific system isn't failing due to a failure of scientific thinking or culture. It's failing due to compounding failures of engineering.

Open source already solved this#

This should sound familiar to anyone in open source, because open source was built by distributed communities precisely to coordinate living, evolving systems. Version control. CI/CD. Dependency management. Package registries. Distributed architecture. Governance models. These are tools for managing software development, an ongoing, collaborative, cumulative process, and science, fundamentally, is exactly the same. A hypothesis evolves. Data accumulates. Code gets revised. Results build on each other. Open source built infrastructure for a system you operate and improve. Science built infrastructure for a product.

AI makes this urgent#

Now layer on AI. The research apparatus is generating results, datasets, analyses, and code at volumes the current infrastructure never imagined. Every AI-assisted study produces more artifacts, more dependencies, and more downstream connections that need to be tracked, identified, and preserved. The infrastructure that was already failing at human speed is about to face machine speed and machine volume. Without intervention, the next decade of research will produce unprecedented volumes of work that can't be reproduced, verified, or preserved.

What needs to be built#

The next generation of scientific infrastructure is an engineering challenge. Here's what it requires:

Cryptographically permanent, free, hyper-granular identifiers for every research artifact. Not just papers, but datasets, code, protocols, reviews, claims, figures, and so much more. Every component, line, and symbol must be independently findable, verifiable, reproducible, and citable.
Modular, independently reviewable components. Research broken into pieces that can be executed, reviewed, funded, and attributed separately.
Interoperable, flexible, on-the-fly adaptable schemas and tooling. Labs working on the same problem must be able to combine their data without losing meaning, and cross-domain use must be possible when the opportunity arises.
Integrated provenance tracking. An automatically generated audit trail from funding to published claim, supported by rigorous evidence.
Reproducible execution environments. Anyone must be able to re-run an analysis and get the same result.
Distributed preservation and compute. No single point of failure, no single funding cut that wipes out a field's data, and compute access for researchers that scales with the compute potential of society.
Large-network governance models. Community governance that works across disciplines, institutions, and borders.

The opportunity#

Governments and funding agencies worldwide are mandating open access, FAIR data, and reproducibility. Billions in research funding now come with these requirements attached. But the infrastructure to actually comply doesn't exist. The engineering brilliance to build it does… in the open source community.

This is a once-in-a-generation infrastructure buildout. Building the next generation of scientific infrastructure requires software architects, maintainers, DevOps practitioners, OSPO leads, community builders, and governance designers. Everyone who knows how to build and sustain systems that work as ongoing processes.

The field is growing. The funding is there. The mandates are real. And the open source community is uniquely positioned to help build the infrastructure that will power science for the next century.

If you've ever thought science wasn't your domain of expertise, think again. It might be the single domain that needs you the most.

Get involved.

Thoughts

MIRA 2026 Workshop

Sustainable Open Source Funding Infrastructure: A Core & Satellite Model for OSS Funding in the Age of AI

A Resilient Data Future — graph.scios.tech

GREP — The Great Research Extraction Project

Lettuce Compute — distributed computing, entering beta

SciOS Compute — compute.scios.tech

SciOS Graph — workshop.scios.tech

PRSM — the MCP ecosystem in one graph

The Core-Satellite Model

Problem#

Why now#

Solution#

The model#

Cores

What a core is not

What a core is made of

Satellites

Core <-> Satellite

The core-commons-system (the meta-layer)

Conflict, competition, and common cores

Roles and beneficiaries#

Goal#

What this model is NOT trying to solve#

Curation and judgment

Artifact stewardship

Satellite lifecycle

Governance

Funding

Agent interface

Services that create gravity

1. The task

2. Finding the cores

3. The agent interface

4. Resolving canonical from noise

5. Reproducible inputs

6. Checking its own work

7. Certification

8. Contributing back

What the example shows

The claim

How it emerged

What it already does

AstroPy as a partial core record

What it has not built

What AstroPy shows

1. The funder's problem

2. Three views of the dependency graph

3. A horizontal core for the mission

4. The deep roots orbit the core

5. The funder makes one decision

6. The money reaches the roots

7. What the funder gets back

What the example shows

1. One person holding a load-bearing library

2. Agents change what the job is

3. Accretion into the core

4. One steward among many

5. Directing agents, not writing syntax

6. Speaking for the work to the outside

7. What changed for the person

What the example shows

If agents do the work, what is left for the people?

What is the difference between orbiting a core and being accreted into one?

Can an artifact belong to more than one core?

Can two cores maintain the same project?

What happens when two cores both want to maintain the same artifact?

If a core accretes my artifact, am I trapped?

Can the same person be in multiple cores?

Do cores orbit each other?

Worked case: AstroPy and SunPy

The Architecture Problem in Research Data#

Four kinds of preservation, only one of which scales

Verification falls out of the architecture

AI runs on the same architecture

The infrastructure already exists

What you need to do

How

"Publishing" Method — 43 questions, 53 claims, 122 pieces of evidence, 6 methods, and 135 sources

What's actually broken#