Source: SoSA Blueprint.md

SoSA Blueprint

Overview

SoSA stands for Society of Societal Architects. It's a secular non-governmental collective volunteer organization that crowdsources distributed human resources towards collectively decided outcomes. SoSA is an opensource software project that utilizes infrastructure that depends entirely on the collective inputs of its members. Each member must contribute towards the collective to be a member in the organization and each member gets to utilize the resources that were built by the members of the organization. It's essentially a Distributated Autonomous Organization (DAO) with a very specific design that ensures the following objectives:-

• Relies on information ecosystem that is built through collectively crowdsourced information using transparent protocols designed to create a single source of truth of the collective narrative. Human beings are animals of information. The narratives, the data, the facts define the spirit of a society. It is sacred. And SoSA aims to keep the integrity of its narrative a vital survival imperative. Our information ecosystem design will gather observations made by each member into falsifiable claims and attach consensus scores for each claim so that everyone knows what everyone else believes with as little interpretation or middlemen of information involved. With this we effectively minimize the potential scope for information distortion through the interventions of agents that manipulate information before passing onto the final witness of that observation. We connect the observers to the witnessers with the observer being the sole agent responsible for the integrity of that claim. We can also build specific scores for each agent that depend on their claim activity and others interaction with them. Each claim can be responded to with 'Agree' or 'Disagree'. Claims can be observational or inferential. Inferential claims are claims made by an agent that infer claims as an extention of an observational claim. Each inferential claim must rest upon another claim. An agent is anyone capable of making a claim. This could be a human being, a bot, a camera (it can make images as claims). Each claim has metadata about the agent responsible for the claim, the spacetime coordinates of the observation being reported, and the spacetime coordinates of the reporting time itself. And when an inferential claim is made, it automatically creates a link between the claim and the inferential claim that is based upon it. If an agent (Agent A) agrees to a claim (Claim A) and posts an inferential claim (Claim B) based upon it, a new link is created between these claims and it would essentially be the claim 'According to Agent A, Claim A supports Claim B'. And a claim's score depends on the consensus of the members. Each claim creation incurs the cost associated with the creation and hosting of that claim, so every claim created requires the establishment of stake by the agent who is making the claim. And every agent use of the ecosystem would require the them to incur the costs associated with retrieving that information. The costs will be calculated on the basis of total cost of hosting the infrastructure for an action divided by the number of agents. The price of operations will be dynamically dependent on the overall health of the ecosystem. All societies operate in this way, but making it completely explicit presents the opportunity for us to be more efficient in coordinating ourselves and be more agile in how we optimize our collective resources towards most favorable outcomes through transparent coordination. An object is an agent that is incapable of creating claims. Each agent gets to have a profile that aggregates all of the agent's activity.

Objectives

The whole point of SoSA is to maximize the coordination of the biological resources that we each possess.

Approach

• Create a new opensource repository on GitHub called SoSA.
• Create the infrastructure for facilitating the mechanism outlined in the overview
• Create modes for each individual to gain a membership to SoSA through taking certain vows and contributing to SoSA in one of the available means of contribution
• One can contribute to SoSA through these ways
  • Money - Required to sustain the resources that SoSA needs
  • Physical Volunteering - Volunteer with manual effort and time
  • Cognition - Constructively participate in the think tank aspect of SoSA that is required to direct the resources that we gather
• After they contribute to SoSA in one of the ways, they must take the necessary vows to become a member of SoSA
• Upon acceptance of membership, they each get a welcome kit shipped to them, with the SoSA Handbook and a SoSA merchandise of their choice - wristband, bandana, cap, T-shirt or something else that has a visible SoSA logo on it. They also get a bunch of SoSA coins that they can use to use across the SoSA ecosystem.
• They can purchase additional, costlier merchandise in the SoSA store and get more coins (monetary contribution)
• All of the details are transparently catalogued and the economy is built through transparency and zero-trust systems

Foundations

• b0 - b0 is short for base0. Base0 is the blockchain of observational claims. Each claim contains the metadata on the agent info, the spacetime coordinates of observation and reporting. The essence of this layer is that human beings simply objectively report their observations in the form of claims, where a claim is an atomic statement that conveys falsifiable assertion.
• Pravada - This is the layer 1 platform that uses b0 as the base to create a consensus-driven roster of classification and scoring of claims. When a claim is made on b0 that is not an observational claim, it does not get registered on Pravada. Because only valid observational claim statements are allowed to be posted without the basis of anothter claim. All claims that do not contain observational claims will not be available on Pravada, and therefore all claims made on the basis of such invalid observational claims will also be de-registered from being visible on the platform. Just to be clear the validity of the observational claim pertains to the the semantic structure of the statement. A valid observational claim could either be empirically true or not. That is decided on the basis of consensus of the members of a Pravada network. Anyone can create a private L1 stack that can have its own principles for the mechanisms for scoring and classification. Pravada is needed as a technology stack to facilitate these networks. It has to be published as a non-commercial open-source technology so that everyone can use it and we can build upon it as a community. The goal of Pravada is to create an information ecosystem that acts as a single model for all the members of the network. So that all of us can synchronize our minds with truth and it's all dynamic. We could have views that allow summarized views of any argument (a composite of many interconnected claims) in various formats. It can have its own APIs for how people can consume the information. Pravada is a way for us to immunize the integrity of the infirmation coming in through our collective sensory nervous sytem. If we can integrate all of our observational capabilities with utmost integrity, that is a significant aspect of coordination abilities for our species.
• SoSA - SoSA is a L2 application of b0. This is where initiatives are tracked on the basis of Pravada. Initiatives are essentially motor nervous system equivalent of what Pravada is to our sensory nervous system. Initiatives allow us to act in coordination to reach collective objectives that we all arrive at consensus for using Pravada. While Pravada is to know what the truth is, SoSA operates on top of it to assess the problems reported by its members. Members are encouraged to post claims about problems that they believe should motivate our collective initiative. These claims can gather supplementary information and everyone who agrees to the claim can support that problem claim with additional information to enrich the problem claim. Over time problems that have garnered the most contributions will rise up in visibility owing to its score. And over time we get to recognize which of the posted problems are most important to the collective (based on the score, as measured by the number of valid claims that support the problem claim). Everyone gets to make only one claim every 24hrs at the standard rate for each claim. This standard rate is the actual cost of creating and hosting the claim. This rate limit helps to ensure that people only create the claims that they truly value. If they choose to make a claim regardless of the standard rate, it will consume x% (let's say 50%) of their total coin reserve. And this input into the revenue stream of SoSA will lower the cost of activities for others in the ecosystem, which means a reduction in the standard rate of claim creation for all. For this to be achieved, we'll have to set a prescribed duration uptil which all pending initiatives must be completed. So the rate at which we spend the coins changes depending on all the things that we've collectively agreed to complete as initiatives. Every member's activity is public and everyone can see how many initiatives anyone has been part of, how many of those were successfully completed, how many were abandoned or went stale. Members also get scored on their contributions. To put it simply, they spend their coins to create claims. And they earn coins by contributing to the initiatives that are active. An initiative is basically a network of interconnected action claims. An initiative could have a start date, end date or it could be a continuous initiative. Even commits to these repos count as contribution to the ecosystem.

Initiatives

These are basically collections of action claims with reward outcomes. When qualifying claims of members having completed that initiative are posted, they get rewarded with coins. The tokens allotted to initiatives control their visibility. And tokens accumulate cumulatively. So even if a few people are interested in promoting an initiative, they have to compensate for it by being committed to investing their rate-limited tokens into that initiative to sustain its visibility. But even with visibility, an initiative needs active reward claims to create incentives for people to complete those action claims to receive the rewards. So a successful initiative requires both tokens of attention invested by members and also sufficient endowment of coins to faciliate the actions. The initiatives themselves can have criteria of completion. Let's say x number of coins spent on valid effort towards certain action claims or some other custom criteria for marking what constitues a completion state for an initiative. An initiative could also be a continuous one.

Each initiative must have a blueprint that acts as the guidelines for how to perform the actions in a valid way. For instance if the problem that was chosen is the drying up of the land and someone came and suggested the initiative of planting trees, one cannot simply allow the planting of a tree to be an action claim that is part of the initiative. These actions must have very specific guidelines that ought to be clear while an action is specified. This is where the transparency of the system becomes vital, because SoSA depends on competition for resources and competing perspectives colliding to create the most refined plan. So oppositional forces would try to undermine the validity of certain actions, like agreeing/disagreeing to the proposals to modify the blueprint and we can have a consensus-driven collective modification to the blueprint and interest driven allocation of tokens to initiatives and coins-driven incentivization of actions that are required to advance the initiative.

Seed initiative

• Create a 60 second video that will hypnotize the viewer and make them understand the essence of SoSA in under 60 seconds. And as the CTA of that video, we get them to visit a link that makes them do something that experientially teaches them how SoSA works. And along the way people who are not ready for SoSA keep dropping off but a large enough number of them watch it, and are able to connect and they perform a few actions that they can do on SoSA, like sharing that video to earn coins, as part of the seed initiative to spread the awareness of what SoSA is. And they get to use the platform as part of this whole ride. It's basically like creating a potent seed of an idea and launching it in the wind to see which fertile mind it lands in so that it can grow and spread itself and unite us all.
• This video is in fact the last step of the whole initiative. Before all this we have to create the various layers of chains on top of which all this will rest. we start with b0, make it infinitely scalable and sustainable and predictable. Then we build pravada and provide a UI to even browse b0. B0 is essentially an offline chain with its basis in the physical location of the data center on which b0 is stored. Pravada connects it to the web. SoSA is built on top of it. Initiatives are filterable according to geography, object of interest among other things. But they're only sorted on the basis of its tokens. Each member of SoSA gets one token allocated for them every 24hrs. They may not possess more than one token at any given time. So it is up to them to either spend their token by placing it on an initiative or forgo their token. Regardless of how many coins anyone has, the token expenditure cannot be more than 1 per 24hrs for each member of SoSA. We must also have transparent verification mechanisms because no one can be a SoSA member without being a verified human being, to ensure uniqueness. They may post problems or initiatives as themselves or through assumed identities (anonymously/pseudonymously). Identities can either be public (in the form of a person assuming the identity of an organization and posting a problem/initiative) or it could be masked (where there is no link between an identity and the actual person who posted it publicly visible; We can examine the complexities around this if needed, but this is to facilitate flexibility of all kinds of problems and initiatives to be reported without repurcussions).
• We can even create initiatives that allows people to participate in the creation of these platforms. Each action claim could be like approved PRs to the repo. There's gotta be some mechanism to regulate this whole thing. Even architecting the design of this platform has to constitute as measurable action claims that can be recorded at least, if not rewarded. So people can simply report their actions as claims whether or not a reward exists for it or not.

---

Source: plan.md

SoSA Folder Reorganization Plan

Executive Summary

SoSA (Society of Societal Architects) is a secular, non-governmental collective volunteer organization concept for crowdsourcing distributed human resources toward collectively decided outcomes. Currently minimal (single file), but detailed technical implementation exists in Clikkin Space Blueprints.

---

1. Content Inventory

Current State

• 1 file: SoSA Blueprint.md (14.6 KB)
• Last modified: Nov 15, 2025
• Git commits: 1 (initial commit)

Related Content (in Clikkin folder)

• Clikkin/Space Blueprints/SoSA Space Blueprint.md (~40 KB) - Detailed technical implementation

Content Structure

Section	Content
Overview	Platform definition, DAO structure, founding principles
Three Layers	b0 (blockchain), Pravada (L1 consensus), SoSA (L2 actions)
Membership	5 tiers (Observer → Chapter Leader)
Governance	Global + City chapters, federated model
Economics	Treasury, coin mechanics, research funding
Initiatives	Problem identification, action claims, rewards

---

2. Key Concepts

Technology Stack

Layer	Name	Purpose
Base	b0	Blockchain of observational claims
L1	Pravada	Consensus-driven classification, "sensory nervous system"
L2	SoSA	Initiatives & actions, "motor nervous system"

Membership Tiers

Tier	Cost	Key Permissions
Unverified Observer	Free	View only, pay-per-action
Verified Member	Free	Free claps, subsidized comments
Sponsor	Rs. 4,999/year	Voting, propose topics, governance
Researcher	Free	Bid on projects, submit deliverables
Chapter Leader	Stipend	Moderation, budget management

Research Funding Workflow

Topic Proposal → Community Voting (30 days) → Budget Allocation → Researcher Selection → Milestone Execution → Impact Tracking

---

3. Questions for Organization

Q1: Relationship to Clikkin

SoSA is designed as a Clikkin Space. Detailed implementation exists in Clikkin folder.

How to organize?

• [ ] Keep SoSA folder minimal (concept only), detailed specs in Clikkin
• [ ] Duplicate relevant content in SoSA folder
• [ ] Move all SoSA content to Clikkin, remove standalone folder
• [ ] Cross-reference both locations

Q2: Document Scope

Current document is high-level overview. Technical details in Clikkin.

What should SoSA folder contain?

• [ ] Concept/vision only
• [ ] Full specification (consolidate from Clikkin)
• [ ] Both concept + implementation

Q3: Expansion Plans

Single document covers many topics (governance, economics, technology).

Preferred organization?

• [ ] Keep as single document (concise reference)
• [ ] Split into multiple documents by topic
• [ ] Expand with additional planning documents

Q4: Implementation Status

Document reads as specification, not active project.

Current status?

• [ ] Active development
• [ ] Planned, not started
• [ ] Conceptual exploration only

---

4. Proposed Folder Structure

Option A: Minimal (concept folder, implementation in Clikkin)

SoSA/
├── overview.yml
├── SoSA Blueprint.md          # Current file
└── archive/

Option B: Comprehensive (if expanding standalone)

SoSA/
├── overview.yml
├── plan.md
│
├── vision/
│   ├── mission_principles.md
│   └── founding_context.md
│
├── architecture/
│   ├── technology_stack.md    # b0, Pravada, SoSA layers
│   ├── governance_model.md
│   └── claims_system.md
│
├── operations/
│   ├── membership_tiers.md
│   ├── economic_model.md
│   └── research_workflow.md
│
├── launch/
│   ├── city_expansion_playbook.md
│   ├── founding_sponsor_strategy.md
│   └── year1_targets.md
│
└── archive/

Which structure?

• [ ] Option A (minimal)
• [ ] Option B (comprehensive)
• [ ] Other: _______________

---

5. Content Consolidation

If keeping both locations (SoSA + Clikkin):

SoSA folder should contain:

• Vision and philosophy
• Governance model
• High-level economics
• Launch strategy

Clikkin folder should contain:

• Technical implementation
• Platform integration specs
• Post categories and automations
• Detailed member flows

Approve this division?

• [ ] Yes
• [ ] Different division: _______________

---

6. Gaps Identified

Missing from current documentation:

1. Legal Structure - Is SoSA registered? DAO status in India?
2. Team - Who is leading implementation?
3. Timeline - When is MVP launch planned?
4. Initial Funding - Source of first 50K coins?
5. Researcher Network - Pre-committed researchers/institutions?
6. Policy Partners - Government engagement?

Priority for gaps?

• [ ] Critical - address before launch
• [ ] Add placeholders
• [ ] Not needed yet

---

7. Cross-References Needed

SoSA connects to:

• Clikkin: Platform infrastructure
• Coredoc: Claims system architecture (b0 layer)
• Pravada: L1 consensus mechanism
• Shuddhi Vidhya: Potential SoSA research topic
• Deepwork: Similar coordination concept

Add explicit cross-references?

• [ ] Yes
• [ ] No

---

8. Files Recommended for Archive

None currently (single file, actively relevant).

---

9. Your Responses

Q1 (Clikkin Relationship): 
Q2 (Document Scope): 
Q3 (Expansion Plans): 
Q4 (Implementation Status): 

Folder Structure: 
Content Division: 
Gaps Priority: 
Cross-References:

---

Generated: 2026-01-22