COSDS Update: What Our Volunteers Have Learned Since Week 3
In the five weeks since our Week 3 update, COSDS volunteers have moved from asking what Janus Facing Architecture (JFA) is to testing whether it holds up, and they have found the questions that will shape the code they write next.
The Community Orchestration Software Development Sprint (COSDS) is NTARI's nine-month, fully remote mentorship program. Volunteers study before they code. At Week 3, the cohort was partway through Introduction to Janus Facing Architecture. Their big takeaway then was that healthy communities aim for "homeostasis, not harmony": disagreement stays survivable and decisions stay open to challenge.
Since then, volunteers finished Intro to JFA, started the four-week Substrate course, and worked through the Accessibility Standards course. Every weekday, a post in #federation-volunteers poses a question about one idea in JFA's "DNA." On weekends, a short biography introduces a thinker behind it. Volunteers answer in threads, and they answer each other.
This article walks through those questions in order, what was asked, what volunteers said back, and the one open problem their work has surfaced: can people safely edit their own view of the software they use?
Finishing Intro to JFA
The cohort finished Introduction to Janus Facing Architecture in mid-September, and the clearest sign of learning was volunteers explaining it in their own words.
On Sept 11, volunteers learned the final was a week away and that the plan had changed. Instead of spreading everyone across every layer, a team of about four would code the first layer's three tiers. That lets each person work in their specialty, frontend, backend or CI/CD, without anyone being forced to work alone. Late starters got a self-paced catch-up course.
As people finished, they posted what they took away:
Eduardo Ospino (Sept 16) saw JFA as a way to organize a system so its parts work together "without everything being mixed in one place," with the Substrate as the foundation for the rest.
Nirmal Khedkar (Sept 16) put it more sharply: JFA "tries to stop too much power from staying in one place." Each layer gives people a way to check decisions, keep records, or leave. His open question was how well that works when the system gets very large.
Dhruv Pathak (Sept 19) wrote a plain-language explainer of the whole architecture.
Dhruv started with the problem. A delivery app shows the driver one screen, the restaurant another and the customer a third. Only the operator sees all three and knows the full economics. "The separation is not a design accident," he wrote. "It is the mechanism of power and control." JFA is named for Janus, the Roman god who faces both ways at once: every side of a transaction can see the whole thing.
He then summarized the five layers:
Substrate: hardware and a protocol the community owns, so no single host or vendor can switch the network off.
Record: an append-only memory of what happened, countersigned by outsiders, so an operator who rewrites history leaves proof.
Covenant: reputation as a promise not to harm, kept as a full distribution rather than an average, so a breach stays visible.
Governance: rules matched to how hard each layer is to leave. Argue where leaving is easy; leave where it is hard.
Economy and Information: credit issued between members instead of by a bank, and knowledge claims that are recorded and cited.
Peter Bao Tran replied that a summary like this "can be referenced easily and helps guide code to follow the JFA model."
The Ideas Behind JFA
Through late September, the daily prompts traced JFA back to its sources, and volunteers kept finding the same tension: how much should be shared, and how much left local?
Keynes and the uniform protocol (Sept 15)
The prompt: JFA is a digital economic model similar to what John Maynard Keynes proposed after World War II, but built through networks instead of the state. NTARI, the 501(c)(3), acts as a "user interface" where members can check how the stack is coordinated, while anyone stays free to develop it in any direction under one shared protocol.
The response: Minkyu Cho went and read about Keynes's International Clearing Union. Countries would stay separate but coordinate through shared rules and a common clearing system. He saw JFA doing the same with protocols instead of central banks, and asked the question that kept coming back all month: how much of the protocol must stay uniform for the network to work, while still leaving communities free to build their own systems?
NTARI founder Jodson Graves pointed to the protocols the internet already runs on, TCP, UDP, IP, HTTP and FTP. A protocol for a field like agriculture can last, or at least survive editing, if its categories are general enough.
Dunbar's number and democracy at postal speed (Sept 16)
The prompt: We rely on representatives because of volume. Dunbar's number caps how many people whose views any one person can really know. Representative democracy was also built around the postal system: people talk at letter speed, governments move in years and quarters, and consensus takes weeks. Computer networks change what time means, and that "gives us a new category of democracy to build."
The response: Minkyu pushed back on speed alone. "Faster communication does not automatically solve the problem of representation." Networks move information instantly, but human attention is still limited. Network governance needs a way to organize many local voices without losing real participation.
Jodson agreed. The speed is built in, but turning it into public will is something software is rarely used for, outside tools like Pol.is, Consul Democracy and vTaiwan.
Elinor Ostrom and fluid roles (Sept 19)
The prompt: "Can you spot Elinor Ostrom's contributions to the JFA concept?" Ostrom won the Nobel Prize in economics for showing that communities can manage shared resources without a corporation or a central authority.
The response: Nirmal found the strongest link in what Ostrom called polycentric governance: many semi-independent decision centers cooperating under shared rules, which is close to JFA's federation. He also found a difference. Ostrom insisted on clear boundaries, where everyone knows who belongs where. JFA allows boundaries between communities but keeps roles fluid inside them.
Asked why, Nirmal answered that Ostrom studied physical resources, like fisheries and water, with fixed groups of users. JFA was designed for digital systems first, where letting one person switch roles helps prevent an imbalance of power.
Fractals and planetary intelligence (Sept 21–22)
The prompts: On Sept 21, Jodson highlighted a favorite question from the week before and answered it: the JFA stack is designed as a fractal, a pattern that repeats at every scale. It can grow to planetary scale, then link to other networks by expanding locally and accounting for transmission delay. The next day's reading was "Intelligence as a Planetary Scale Process" by Adam Frank, David Grinspoon and Sara Walker, alongside Vladimir Vernadsky's The Biosphere. The question: where do software and the internet fit in their picture?
The responses:
Harsh Bhandari liked the fractal idea but saw its limit. Messages between distant parts of a network get slower and less consistent, so the cohort needs to decide how much independence each local unit gets before global coordination becomes a bottleneck.
Peter placed software in the "technosphere," the third stage after the geosphere and biosphere. He compared software to a fungal network that links plants across a forest and passes signals between them.
Nirmal added that software doesn't just connect the technosphere. It creates feedback loops that change real-world behavior, which is close to what the authors mean by planetary intelligence.
Harsh concluded that JFA's job is not to centralize intelligence but to provide repeatable structures for local coordination. "If planetary intelligence is possible, I would like it to emerge from a federated feedback instead of one single decision maker."
Jodson called the paper "key to understanding what we are doing here": technology that helps unite humanity's shared thinking could bring lasting peace, "not through coercion."
Who JFA is for, and who checks the work
The busiest thread of the month started with a list of community networks and ended with a concrete design for verifying work nobody can watch directly.
The prompt (Sept 24): "If you don't have a market in mind for the JFA stack, these are just a few of the many examples I have in mind": Guifi.net in Catalonia, NYC Mesh, Germany's Freifunk, Italy's Ninux and Sarantaporo.gr in rural Greece. All are networks that communities build and run themselves.
The pattern
Harsh read through all five and named what they share. They have already solved physical decentralization by letting communities build and own the infrastructure. Guifi calls itself a self-organized infrastructure commons. NYC Mesh is owned by the people who run and use it. Freifunk is hundreds of local groups.
NTARI vice president Calvin Secrest proposed a market on top of them: SoHoLINK, which lets people rent the spare power of their home computers to run small AI jobs. Mesh networks have built the roads, he argued, but those roads still lead back to big cloud companies. Selling affordable compute could fund the community networks and pay everyday owners instead of large data centers. Harsh saw it as the same pattern "one layer higher": once people own the infrastructure locally, JFA can coordinate how it is shared.
The catch
Minkyu named the problem. Decentralizing the hardware "does not automatically create a trustworthy market." If many people share their own devices, the system still needs to know which ones are reliable, how much each person actually contributed, and how to reward them.
Jodson answered that this is the other layers' job. The Covenant keeps reliability readable. Contributions are tracked as protocol transmissions in the Record. Rewards follow the cost of production at each producer. "Trust is a network of expectations," he wrote. "The Covenant creates it, but exists almost like a nervous system within the stack."
Dhruv then found the gap. Guifi.net already runs a compensation system: members who use more than they contribute pay those who contribute more, and the total nets to zero. But it relies on costs each member declares, so there is an incentive to overstate them, which Guifi has seen. And "a signature proves who made the claim, not that the work was done correctly." He asked two questions:
What independently checks a compute result?
Who witnesses the Record?
The answer
Jodson's reply turned both questions into design:
Checking results: the system audits itself. A render job, for example, can run on two machines independently. That costs more, but the second run is both a check and a failsafe. Physical production like printing is harder to check, but the Covenant keeps unreliable producers visible either way.
Witnessing the Record: the Record runs on the Substrate, with members paid to provide storage. Each record is a hash, a short digital fingerprint, of a transmission between operators and the members they serve. Copies are held by two independent witnessing services the operator must buy, by the members in the transaction, by the operator, and by the Record layer itself: six independently held copies in all.
Calvin summed up how it fits together. Home users run a lightweight SoHoLINK program over ordinary web connections, with no router setup. A scheduler sends small jobs to nearby devices and runs some twice to catch cheaters. Six witnesses sign receipts, owners get paid right away, and the Covenant keeps everyone accountable.
Reading Dune: trust and the cost of leaving
Two days on Frank Herbert produced one of the cohort's sharpest ideas: the real test of a system is not whether it seems trustworthy, but what it costs you to stop trusting it.
The prompt (Sept 25): Herbert began publishing Dune around the time the internet's core protocols were being invented. Volunteers watched a video covering the series' 34,000-year fictional history and were asked what Herbert was saying. Jodson offered his own theory: Herbert saw no way out of central governance in an analog world, and built a universe to explore how humanity might escape it, while the answer was being invented around him.
The biography (Sept 26): Herbert was among the first science fiction writers to popularize ecology and systems thinking. He kept asking "What is sane?" and suggested that "normal" and "abnormal" are labels people are poorly equipped to apply to each other.
The responses:
Nirmal read Dune as a warning about putting too much power in one person or system. Paul is capable and well-meaning, but people become dependent on him. "The problem is not only the leader. The problem is a system that needs one person at the center." Protocols that let people coordinate and verify information without one institution are a direct answer.
Minkyu saw the long timeline as the point. The future in Dune is less a prediction than "a test of whether people can learn from systems before becoming trapped by them." On the biography, he added that a system can become so familiar people stop noticing its problems. Good systems make it possible to question the rules instead of accepting them because they have always been there.
Dhruv took it a step further. Herbert said he wrote Dune because charismatic leaders should come with a warning label, and summed up the trilogy as "beware of heroes." The danger isn't only bad actors taking over a system. It's people handing their judgment to trustworthy-looking ones.
Dhruv's conclusion reframed the question for builders: "We usually ask 'is this platform or institution trustworthy?' Herbert would ask 'what does it cost you to stop trusting it?'" When your history, relationships and reputation are locked inside a system, people stop questioning it, not because they agree, but because leaving costs too much. "Normal becomes a gravity well."
That is exactly the principle behind JFA's Governance layer, which sets the rules for each layer by how hard it is to leave.
Testing the philosophy
The week of Sept 28 asked volunteers to find the weak spots in NTARI's own philosophy, and their sharpest finding was that disagreement is data, not noise.
Each day paired an NTARI essay with the same kind of question: where does this idea hold, where does it break, and how does it show up in the architecture?
Maximum Observational Diversity (Sept 28)
The prompt: Read Maximum Observational Diversity (MOD), the idea that we should trust a conclusion more when many independent observers reach it. "Where is it a strong stance, where is it weak? How is it applied to the architecture?"
The responses: Nirmal named both sides. MOD is strongest in saying we should trust a result more when independent observers agree. Its weakness is that "independent" is hard to prove, since observers can share the same assumptions and biases. In JFA, MOD shows up as avoiding a single source of truth: nodes observe and verify on their own, and confidence comes from their agreement, not one authority.
Harsh built on that. If independence is hard to prove, MOD shouldn't treat agreement as the only useful signal. "Persistent disagreement can be of value too since it may end up exposing blind spots." The network should keep multiple observations with their context, so it can tell real agreement from artificial agreement.
Minimum Sustainable Projection (Sept 29)
The prompt: Read Minimum Sustainable Projection (MSP), the other side of MOD. "Where does it break down, where does it work? How does it tie into the JFA?"
The responses: Nirmal summed up MSP as: build around what you can actually observe, and assume as little as possible. It works when a system keeps testing its assumptions and breaks when people treat them as permanent truth. That's why it pairs with MOD, since more viewpoints catch bad assumptions.
Harsh found a subtler failure. MSP is most useful when it forces a system to justify what it assumes. But some systems need explicit rules and defaults to work, and if too much is left undefined, "the ambiguity itself becomes a source of hidden control." In his view, JFA handles this well: it keeps roles and assumptions minimal, but makes the ones that remain visible and open to challenge.
The Scientific Method as Ritual (Sept 30)
The prompt: The Scientific Method as Necessary Ritual, the bridge between MOD and MSP.
The response: Nirmal tied the three together: "MOD finds patterns, MSP builds around them, and the scientific method is the filter in between." Calling it a ritual makes sense, he wrote, because science only works when people repeat the same habits: doubt the claim, test it, let others challenge it, reproduce the result. That keeps MOD from mistaking coincidence for truth before MSP turns it into infrastructure.
Do democracies follow these principles? (Oct 1)
The prompt: Read The Material Culture of Democratic Deliberation and consider whether representative democracies around the world observe MOD, MSP and the Scientific Ritual.
The responses: Nirmal pointed to the essay's distinction between transparency and participation. Letting people see what government does is useful, but it doesn't mean their observations feed back into decisions. Democracies have some of the ritual, but it is "much less continuous and adaptive."
Harsh agreed. Representative democracy has debate, opposition and elections, but those loops are periodic and heavily filtered. For JFA, participation should be "properties of the system itself" rather than an occasional input into a fixed structure. He added a caution: the system needs a clear line between keeping observers independent and letting them repeat the same assumptions, or it "may end up converging for the wrong reasons."
The thread drew in staff too. Jodson and Calvin described JFA as political theory for networked communities "that preserves liberty." Calvin traced how the same principles could apply to healthcare, keeping patient records under local control instead of with large centralized vendors.
The Substrate course: what forkability really means
The four-week Substrate course covers JFA's first layer, the hardware and protocol a community owns. One week in, it had already changed how volunteers think about open source.
The assignment: Volunteers who finished Intro to JFA enrolled in the Substrate starting Sept 15. Week 1 introduces the community-owned protocol and the open problems it still faces.
The response: Harsh posted that the course "completely changed my opinions" on forkability, the ability of anyone to copy a project and carry it on independently. He used to see it as keeping code open and light on dependencies. Now he sees it as whether someone can rebuild the protocol from the written spec alone and get exactly compatible behavior.
"Think of it as the difference between being given a restaurant kitchen and being given a recipe," he wrote. Real forkability means the recipe is precise enough to cook the same dish anywhere, with different tools.
He also spotted the tradeoff in the course's open problems. Storage proofs, verification and signatures all make the protocol more robust. But every added mechanism risks the principle it protects: staying lightweight, free of dependencies and easy to fork. It is the same tension the markets thread hit from the other direction: the more checking the system does, the heavier it gets.
The Accessibility Track: From WCAG to Presentation Sovereignty
The Accessibility Standards course starts with the rules every website should meet and ends with a harder idea: users should be able to change how software looks for themselves.
The ten-week course runs in #rand-accessibility. Weeks 1–3 teach the standards (WCAG 2.2, the web's main accessibility guidelines), the axe-core testing engine, and the limits of automated testing. Week 4 is the turning point. Weeks 5–10 design and build an editor that lets users restyle their own view safely.
The floor, not the goal
Nirmal finished the course in September expecting accessibility to mean passing checklists, supporting keyboard navigation and fixing what tools flag. He left seeing those as "an important minimum rather than the full goal." A page can pass every automated check and still not fit a particular person, which is why users need some control over how pages look. His open question: how can a page keep its structure sound while handing that control to users?
Peter Bao Tran has posted every week, and his work traces the course arc.
Week 2, testing tools: He ran axe on three sites and found 292 issues on one, 5 on his own and none on a federal site. He then found a problem on that "perfect" site the tool missed: a search icon covering the text people type.
Week 3, automation's ceiling: He wrote an automated test for WCAG 2.4.2, which requires every page to have a title. The test checks the title exists, then attaches it to the report beside the page text so a person can judge whether it fits. He linked the split to "homeostasis, not harmony": automation and human judgment each do their part.
Week 4: From Conformance to Sovereignty
The prompt: All the standards so far improve what the author builds. None of them change who controls what the user sees. The web was originally built the other way: browsers let readers apply their own stylesheets, and a reader's !important rule beat the author's. JFA makes that a guarantee called presentation sovereignty: every participant can restyle their own view, styling ships as data users can edit, and the default theme must still meet WCAG AA. Volunteers wrote a one-page position note on where this extends the accessibility tradition and where it might pull against it, using one hard case: a user restyles their own view below AA contrast. Whose problem is that? They also predicted three ways a "paste any CSS or HTML" feature could be abused.
The response: Peter argued that presentation sovereignty extends accessibility, and traced it through CSS !important, the browser's built-in stylesheet and WCAG's focus-indicator rules. On the hard case, he wrote that the scope of the change is what matters. The default has to meet AA. If a user's choices affect only their own view, "no liability should be held as long as JFA has done its part correctly."
Week 5: The Five Requirements as a Threat Model
The prompt: "Let users paste CSS and HTML into the app" is, stated naively, "a security incident with a settings page." JFA answers with five rules, each built against a specific attack:
No scripts, ever. Themes can change structure and appearance only. An allowlist filter keeps known-safe code and deletes everything else.
No outside requests. CSS can load images and fonts from other servers, which a malicious theme can use to track people or leak what they type. All outside links are stripped on import.
Reset lives out of reach. One line of CSS can hide the whole page, including the undo button. Reset must sit where user styles can't touch it, with a backup that needs no screen at all.
Plain, portable files. Themes import and export as ordinary CSS anyone can read.
No hiding accountability in shipped themes. Users may hide anything in their own view. But any theme the platform itself ships must keep Covenant information, like harm records, visible.
Volunteers graded their Week 4 predictions against the five rules and posted their cleverest attack.
The response: Peter graded himself honestly: his predictions were "way off" because he hadn't tied them to JFA principles. (Two of the three actually matched rules 1 and 3.) His attack aimed CSS at a form field's focus state to go after login tokens stored in the browser. It's a good example of why the first two rules work as a pair. CSS on its own can't read stored data or run code, so once scripts and outside requests are blocked, that route closes.
Week 6: Designing the Editor
The prompt: Design the editor before coding it. It must be immediate (edits show live), reversible (reset is always one action), legible (users see real CSS), honest at the border (import reports what it removed) and visibly scoped (it says plainly that changes affect only your view). The editor itself has to meet WCAG AA. The key decision is the boundary: "too much protected chrome and you've built a permissions system; too little and requirement 3 fails."
The response: Peter's design put the editor's controls in a protected layer that user CSS can't reach or cover. He defended that line in the course's own terms: the protected area only needs what it takes to see, edit or undo the custom view. Inside, changes apply live, and shortcut controls for text size, contrast, font and background write visible CSS into the editor. Imports are cleaned of outside links and scripts, with a report of what was removed. Reset sits in a top strip with Undo, and a pinned notice says changes affect only your view. His escape hatch is a web address ending in ?userstyle=off, which pauses the custom view without deleting it.
The open question: can a theme lie?
The accessibility work raises a question anyone would ask: can users really edit their own view of an app without opening security holes? Mostly yes. The remaining risk is deception, not theft, and that is the question the cohort takes up next.
What the five rules already handle
If edits are limited to appearance, apply only to the user's own screen, and are cleaned on the way in, the worst a bad edit can do is break or distort that one person's view, and Reset fixes it.
CSS can't run code. Its only real dangers are reaching outside servers and hiding the page. Stripping outside links on import closes the first. A Content Security Policy, a list of approved servers the site gives the browser, blocks anything the filter misses. The protected Reset and escape hatch close the second.
HTML is the harder half. Scripts can hide in many places: image error handlers, javascript: links, SVG files, embedded frames. The defense is two walls: an allowlist filter that deletes anything not known to be safe, and a security policy that blocks inline scripts in case the filter is ever bypassed. A cautious first version could skip raw HTML entirely and let users only rearrange or hide existing parts of the page.
None of this is new territory. Browsers let readers apply their own stylesheets for decades.
What engineering can't fully solve
A theme can't steal anything, but it can mislead. With plain CSS it can relabel a button, hide a warning, or make "Decline" look like "Confirm." Self-view-only protects everyone else from your theme. It doesn't protect you from a theme someone else wrote and passed around.
JFA deliberately lets users hide anything in their own view, even Covenant information. So the defenses today are readable themes, an import report, and the user's own judgment. Whether that is enough is an open design question, and it is the Week 7 discussion.
The Week 7 discussion prompt
Can a theme lie?By now our editors block the obvious attacks. Themes can't run scripts, can't contact outside servers, and can't hide the Reset button. But a theme doesn't need code to cause harm. With plain CSS it can relabel a button with ::before { content: ... }, hide a warning, or make "Decline" look like "Confirm."Self-view-only protects other people from your theme. It doesn't protect you from a theme someone else wrote and passed around the community.JFA deliberately lets users restyle anything in their own view, even Covenant information. So here's the question:
Should any part of the page be protected from user styling beyond the Reset controls? If so, what goes on that list, and why?Where's the line? Signing a record, paying, confirming a transaction, and Covenant harm records are all candidates. Pick what you'd protect and defend each choice.What does it cost? Every protected item takes some sovereignty away from the user. When does a protected list become the permissions system we said we'd avoid?Is there a design answer instead? Could readable CSS, the import report, or a warning like "this theme changes button labels" solve this without protecting more of the page?Post your answer, then respond to two classmates. At least one response should argue against their list.
The question echoes the rest of the month. Harsh warned that too much left undefined becomes "hidden control." Dhruv asked what it costs to stop trusting a system. The cohort now has to decide where the user's freedom to reshape their screen ends and the system's duty to keep certain things visible begins.
How volunteers are learning
Volunteers aren't only absorbing the material. They are building study habits, teaching each other, and helping shape how the workspace itself runs.
Using AI as a tutor (Sept 18)
The prompt: "How many of you used AI to take your quizzes for Intro to Janus Facing Architecture? And if so how did you build context so it can help you be an expert as we build?"
The responses: Harsh sorts every reading into three piles: parts he can understand and explain, parts he understands but can't explain, and parts he doesn't get yet. For the middle pile, he asks AI for real-life examples. For the last, he reads more and sometimes has AI draft pseudocode he can assemble, "similar to how we used to use Stack Overflow before AI."
Dhruv gives AI the reading first, then has it quiz him. Questions he misses become a second, narrower quiz, then a set of harder follow-up questions. He often asks for a diagram, and carries the same conversation forward so the AI knows his strengths and gaps.
Writing things down (Sept 17)
The prompt: GitLab's remote-work handbook uses emoji reactions to pass information, like 👀 for "I've seen this." NTARI does the same: 🧬 marks the daily post and ☣️ marks the weekend biography. GitLab deletes chat after 90 days. NTARI keeps posts up for good, as an unofficial handbook and research record.
The response: Nirmal liked that GitLab pushes long-term knowledge into wikis instead of chat that gets lost. Jodson noted that when NTARI builds the Governance-layer tool that replaces Slack, creating those wikis automatically will likely be a feature.
Hands-on practice
On a Sept 14 prompt about cybersecurity learning tools, Dhruv drew on his security career: auditors miss key issues without foundational knowledge, so "for any cyber related careers or courses, first a networking base is a 100% must." He recommended practice platforms like TryHackMe.
Going beyond the syllabus
Nirmal enrolled in the Covenant course alongside the Substrate. Jodson called it out to the whole channel: all NTARI.org courses are free, volunteers are encouraged to study any layer, and the code stays theirs to use under the AGPL-3.0 license wherever they go next.
What's next
The cohort is getting ready to code, and many of the questions above now become design work.
The coding sprint. A team of about four will build the first layer's three tiers: protocol, orchestrator and frontend. A 21-week coding session is ahead, and volunteers are submitting resumes now.
Task tracking. Jira epics now exist for all five layers: the Substrate, the Covenant, the Record, Governance, and Economy & Information. Task progress posts straight to Slack.
Accessibility joins the Substrate. After the Substrate course, accessibility volunteers will work across #rand-accessibility and #rand-substrate on WCAG compliance and NTARI's accessibility tools. Weeks 7–10 of the accessibility course move from design to building and hardening the editor.
Code to build on. On Oct 1, NTARI published first releases of Cloudy (v0.1.0) and SoHoLINK (v0.1.0), plus sohocloud-protocol v0.3.0. Cloudy now ties 4 of its 23 JFA rules to automated tests, including a check that records can never be edited or deleted, only corrected with a new entry.
The questions volunteers raised, like who checks a compute result, how much of the protocol must stay uniform, and whether a theme can lie, are now problems the cohort will help solve in code.
Sources
Intelligence as a Planetary Scale Process (Frank, Grinspoon and Walker)
NTARI Accessibility Standards course, Weeks 4–6, on NTARI.org
#federation-volunteers, #rand-accessibility and #rand-substrate, NTARI Slack, Aug 29 – Oct 3, 2026
Comments