Ragav's Projects

Appearance

Source: summary.md ​

Folder Organization Template ​

Use this template to organize other research folders in 1. research/ following the same pattern applied to Coredoc.

Quick Reference: Organization Process ​

Phase 1: Analysis ​

  1. Explore folder contents (files, subfolders, sizes)
  2. Read key files to understand themes and purpose
  3. Check git history for chronological evolution
  4. Identify conflicts, redundancies, and superseded versions

Phase 2: Plan Creation ​

Create plan.md with:

  • Content inventory
  • Critical conflicts requiring resolution
  • Open questions for decision-making
  • Proposed folder structure
  • Files recommended for archive
  • Response section for user input

Phase 3: Reorganization (after user input) ​

  1. Create folder structure
  2. Move superseded files to archive
  3. Create overview.yml navigation index
  4. Extract/create concept files for subfolders
  5. Create summary.md for future reference

Standard Folder Structure ​

[Project]/
├── overview.yml              # Navigation index (REQUIRED)
├── plan.md                   # Organization decisions (keep for reference)
├── summary.md                # This template (for future reorganization)
│
├── paper/                    # Primary output (if research paper)
│   ├── [paper_name].md      # Canonical paper in markdown
│   └── figures/             # Supporting visuals
│
├── theory/                   # Core concepts (max 3-5 files)
│   ├── [concept_1].md
│   ├── [concept_2].md
│   └── [concept_3].md
│
├── implementation/           # Technical/practical details (if applicable)
│   ├── architecture.md
│   └── algorithms.md
│
├── references/               # Source materials
│   ├── literature_review.md # Collected citations
│   └── [source_pdfs]/       # Primary sources
│
└── archive/                  # Superseded versions (ALWAYS INCLUDE)
    └── [old files]

Structure Variations ​

For pure theory/research projects: Use full structure above

For minimal projects:

[Project]/
├── overview.yml
├── [main_content].md
├── references/
└── archive/

For implementation-focused projects:

[Project]/
├── overview.yml
├── spec/
├── implementation/
├── references/
└── archive/

overview.yml Template ​

yaml
# [Project Name] Overview
# [One-line description]

project:
  name: [Name]
  subtitle: [Subtitle or tagline]
  status: [research_paper | concept | implementation | complete]
  author: [Author name]

summary: |
  [2-4 sentence description of the project's purpose and scope]

core_concepts:
  - name: [Concept 1]
    description: [One-line description]
  - name: [Concept 2]
    description: [One-line description]

folder_structure:
  [folder]/:
    description: [Purpose]
    files:
      - [file.md]: [Description]

key_decisions:
  [decision_area]: |
    [Explanation of key decision made during organization]

next_steps:
  - [Action item 1]
  - [Action item 2]

last_updated: [YYYY-MM-DD]

plan.md Template ​

markdown
# [Project] Folder Reorganization Plan

## Executive Summary
[Brief description of current state and goals]

## 1. Content Inventory
### Current State
- [X] root files
- [Y] files in subfolders
- Key themes: [list]

### Chronological Evolution
1. [Earliest file] - [description]
2. [Next file] - [description]
...

## 2. Critical Conflicts Requiring Resolution

### CONFLICT A: [Name]
[Description of conflict]

**Your clarification needed:**
> [Question]
> - [ ] Option 1
> - [ ] Option 2
> - [ ] Other: ___

[Repeat for each conflict]

## 3. Open Questions

### Q1: [Question topic]
> [Detailed question]
> Response: ___

[Repeat for each question]

## 4. Proposed Folder Structure
[Show proposed structure]

## 5. Files Recommended for Archive
| File | Reason |
|------|--------|
| [file] | [reason] |

## 6. Your Responses
[Section for user to fill in]

---
*Generated: [date]*

Decision Principles ​

What Goes in Archive ​

  • Superseded versions (V1, V2 when V3 exists)
  • Duplicate formats (.docx when .md is canonical)
  • AI-generated drafts that were refined
  • Old notes incorporated into main content
  • Exported formats (PDF) that can be regenerated

What Stays Active ​

  • Canonical/latest version of main content
  • Reference materials (literature reviews, source PDFs)
  • Structured concept files
  • Navigation files (overview.yml, plan.md)

Naming Conventions ​

  • Use lowercase with underscores for new files: concept_name.md
  • Keep original names for archived files (preserves history)
  • Use descriptive names: literature_review.md not refs.md

Folder Limits ​

  • Maximum 5 subfolders (excluding archive)
  • Maximum 5 files per concept folder
  • If more needed, consider sub-subfolders or consolidation

Conflict Resolution Patterns ​

Framing Conflicts ​

When multiple framings exist, determine if they are:

  • Hierarchical: Micro vs macro views of same phenomenon (keep both, clarify relationship)
  • Evolutionary: Earlier vs later thinking (archive earlier, keep latest)
  • Complementary: Different aspects (consolidate into unified view)
  • Contradictory: Genuinely incompatible (user must choose)

Scope Conflicts ​

  • Identify intended scope from most recent notes/instructions
  • Archive out-of-scope content rather than deleting
  • Document scope decisions in plan.md

Version Conflicts ​

  • Use git history to determine chronology
  • Most recent = canonical (unless explicitly superseded)
  • Keep one format as canonical (recommend .md for git-tracked research)

Checklist Before Completion ​

  • [ ] overview.yml exists and accurately describes project
  • [ ] All superseded files moved to archive/
  • [ ] No duplicate content in active folders
  • [ ] Each subfolder has clear, distinct purpose
  • [ ] Concept files are self-contained and reference each other appropriately
  • [ ] plan.md preserved with decisions documented
  • [ ] summary.md present for future reorganization
  • [ ] Git commit made with descriptive message

Example Prompt for Next Folder ​

Organize the [FolderName] folder following the pattern in Coredoc/summary.md:

1. Analyze all content for themes, conflicts, and redundancies
2. Create plan.md with questions for my input
3. Wait for my responses
4. Execute reorganization with:
   - overview.yml navigation index
   - Appropriate subfolder structure (max 5)
   - Archive for superseded content
   - summary.md for future reference

Template version: 1.0Created from Coredoc organization: 2026-01-22

Source: plan.md ​

Coredoc Implementation Plan - Updated Architecture ​

Executive Summary ​

Major architectural shift from "immutable claims" to "immutable claim statements with mutable truth values." This enables personal coredocs where each member maintains their own truth assignments to a shared blockchain of claim statements. This plan addresses the implementation of this new model and the Pravada social platform.

1. Core Architectural Changes ​

New Model: Boolean Claims with Personal Truth Assignment ​

Previous Model (V5 paper):

  • Claims are immutable L1 blocks
  • Each claim is either true or false in absolute terms
  • Different agents may have different claims

New Model (overview.yml new_notes):

  • Claim statements are immutable (blockchain)
  • Claim truth values are personal and mutable (per-member coredoc)
  • Everyone references same claim statements, but each assigns own truth value

Claim Object Structure ​

json
{
  "id": "unique reference ID",
  "claim": "atomic boolean statement",
  "truth": true | false | null,  // Personal truth value
  "author": "user_id",           // Nominator if accepted from others
  "type": "observational | inferential",
  "antecedents": ["claim_id_1", "claim_id_2"],  // Array of prerequisite claims
  "spacetime": {
    "location": "coordinates",
    "datetime": "ISO timestamp"
  },
  "created": "datetime of addition to member's coredoc",
  "updated": "datetime of last modification"
}

2. Critical Questions for Clarification ​

QUESTION A: Truth Value Semantics ​

The new model allows truth: true | false | null.

What does each state mean?

  • true: I believe this claim is correct
  • false: I believe this claim is incorrect
  • null: I acknowledge the claim exists but haven't evaluated it / unknown truth value

Clarification needed:

  1. Can I have a claim in my coredoc with truth: false?

    • [x] Yes - I'm tracking claims I believe are false
    • [ ] No - false claims should not be in my coredoc at all

  2. What's the difference between:

    • Claim with truth: false in my coredoc
    • Claim not in my coredoc at all If a claim exists in the coredoc, it means that that claim is being tracked by the person, because it oculd be of interest or maybe they're waiting for ensuing dialogue based on the claim to make up their mind. Essentially it's like bookmarking an idea that they're not sure is valid or not. Think of it like a hypothesis that is yet to be validated. If the claim is marked as false, it means that the claim has been personally verified as being false.

  3. Is null a temporary state (haven't decided yet) or permanent (unknowable)?

    • [x] Temporary - will eventually become true/false
    • [ ] Can be permanent - some claims are fundamentally unknowable

QUESTION B: Antecedent Logic with Boolean Truth Values ​

If I have an inferential claim that depends on antecedents:

json
{
  "claim": "Heat was added to water",
  "type": "inferential",
  "antecedents": ["claim_A", "claim_B"],
  "truth": true
}

What happens if I set one antecedent to false?

  • [ ] Auto-update: My claim's truth becomes false automatically
  • [ ] Warning: System warns but lets me keep inconsistent state
  • [x] Cascading review: Triggers review but I decide
  • [ ] Flexible: Logic not enforced, I can have inconsistent beliefs

Your note says: "updating truth value must trigger review of antecedent claims"

  • Does this mean downstream claims (those that depend on this) or upstream (this claim's dependencies)?

Both.

QUESTION C: Observational vs Inferential Truth Values ​

Observational claims are personal experiences. Inferential claims are deductions.

For observational claims about MY subjective experience:

  • Example: "I felt pain at 10am"
  • Can anyone else set this to false in their coredoc?
    • [x] Yes - they can disagree with my experience, but it wwill be updated in their personal coredoc, not mine.
    • [ ] No - only I can claim my subjective observations

For observational claims about EXTERNAL reality:

  • Example: "Temperature was 23.5°C at location X, time Y"
  • Different people may have different truth values (measurement error, different instruments)
  • Is this acceptable or does it indicate measurement error that should be resolved?
    • [x] Acceptable - multiple observers, multiple truths
    • [ ] Error - need reconciliation process

the claims will all rest in one blockchain and members can import those claims into their respective coredoc and assign their own truth values to the claims in their coredoc.

QUESTION D: Public vs Private Claims ​

You mention a flag for public/private.

Visibility Cascading Rules:

  • If claim C has antecedent A, and C is public, must A be public?

    • [ ] Yes - can't have public claim with private basis
    • [x] No - can reference private antecedent (ID visible, content hidden)

  • If I make claim A private, what happens to claims C that depend on it?

    • [ ] Auto-cascade: C becomes private too
    • [ ] Warning: System warns but I decide
    • [x] Flexible: C can stay public, just shows "private antecedent"

QUESTION E: Blockchain Claim Deduplication ​

You state: "1:N duplication prevention every time new claim added"

How is duplication detected?

  • [x] Exact text match (case-sensitive)
  • [ ] Semantic similarity (NLP-based)
  • [ ] Hash of claim content
  • [ ] Manual review by claim creator

Since we're using exact text match, we should also have the essential protocol to constrain the framing of a claim to maintain consistency. This means establishing strong conventions for objects/places/agents being referenced through their id and have conventions for how measurements are listed (they can be listed a certain way and referenced in multiple ways depending on who's viewwing it. For instance it could be listed as 23.5 degree celcius or 23.5C or something gelse depending on the viewer's prference, but the actual statement would have a standard notation for all measurements and standard conventions for pretty much all claim statements). We might need to explore the options and edge cases on this.

Example edge cases:

  • "Water temperature was 23.5°C" vs "Water temp was 23.5 degrees Celsius"

    • Are these duplicates? _______________

  • "I observed X" vs "John observed X" (same observation, different agents)

    • Are these duplicates? _______________

QUESTION F: Claim Nomination/Acceptance Flow ​

You mention: "I can suggest addition of claim to someone else's coredoc"

Nomination workflow:

  1. Alice creates claim on blockchain (or finds existing claim)
  2. Alice nominates claim to Bob
  3. Bob receives nomination and can:
    • [x] Accept with truth=true
    • [x] Accept with truth=false
    • [x] Accept with truth=null
    • [x] Reject (claim never enters Bob's coredoc)

Clarification:

  • If Bob accepts with truth=false, does author field become Alice or Bob?
  • You said: "if they accept it as nominated by someone else, then it would be the user id of the person who nominated"
  • So author = nominator, not creator of claim on blockchain?

Author will always be the one who created the claim on the blockchain.

QUESTION G: Personal Coredoc vs Shared Blockchain ​

You state: "individual member coredoc files are just references to claims in blockchain"

Data model architecture: Blockchain (shared, immutable):

json
{
  "claim_id": "uuid",
  "claim_statement": "atomic boolean text",
  "type": "observational | inferential",
  "original_author": "user_id who first created this on blockchain",
  "created_on_blockchain": "datetime",
  "spacetime": { ... }  // Of original observation/inference
}

Personal Coredoc (per-member, mutable):

json
{
  "claim_id": "reference to blockchain claim",
  "truth": true | false | null,
  "antecedents": ["claim_id_1", ...],
  "visibility": "public | private",
  "added_to_my_coredoc": "datetime",
  "last_updated": "datetime",
  "nominated_by": "user_id or null"
}

Is this the intended architecture?

  • [x] Yes, exactly
  • [ ] Modifications needed: _______________

QUESTION H: Antecedents - Blockchain vs Personal ​

Claim statements on blockchain don't change. But antecedent relationships might vary per person.

Where are antecedents stored?

  • [ ] Blockchain: Antecedents are part of immutable claim statement
  • [x] Personal Coredoc: Each person defines their own antecedent links
  • [ ] Hybrid: Original author's antecedents on blockchain, others can override in personal coredoc

Example:

  • Alice creates inferential claim "Heat added to water" with antecedents [A, B]
  • Bob accepts same claim but believes different antecedents [C, D] support it
  • Is this allowed? _______________

Relationships are never stored on the blockchain, only on the personal coredocs of the members. ​

3. Algorithm Development Requirements ​

Based on new_notes, you need these algorithms implemented in Python:

Algorithm 1: Claim Creation & Validation ​

Location: implementation/algorithms/claim_creation.py

Requirements:

  • Validate claim is atomic (boolean, single assertion)
  • Check for duplicates on blockchain (prevent duplicate addition)
  • Assign unique claim_id
  • Log successful claim creation
  • Questions:
    • Validation rules for "atomic" - how to detect compound claims?
    • Duplicate detection method (see QUESTION E above)
    • Who can create claims on blockchain - anyone or only verified users?

We need to have a strong algorithm that specifies universal notations for all kinds of observations and inferences to be created in standard formats. This is the only way to achieve true de-duplication using exact match. This is tricky but I suppose can be achieved. This is the algorithm where we must establish the conventions for how object definitions ought to be claimed before they can be used as references in other claims. The definitions themselves ought to be in the claims in the blockchain and have universal conventions that facilitate all kinds of claim creation.

Algorithm 2: Truth Value Update ​

Location: implementation/algorithms/truth_value_update.py

Requirements:

  • Update truth value in personal coredoc
  • Trigger review of antecedent claims
  • Questions:
    • What does "trigger review" mean? Auto-update? Show warning? Create task list?
    • Cascade upstream (to antecedents) or downstream (to dependents)?
    • Handle circular dependencies how?

This pertains more to the UX flow on Pravada, not necessarily directly tied to the coredoc protocol itself. The protocol itself can handle internal inconsistencies. The platform pravada will attempt to promote consistency of coredocs through forced reviews.

Algorithm 3: Antecedent Management ​

Location: implementation/algorithms/antecedent_management.py

Requirements:

  • Add antecedent to existing claim
  • Remove antecedent from claim
  • Validate: All inferential claims must have ≥1 antecedent
  • Questions:
    • Can I remove last antecedent from inferential claim? (would violate constraint)
    • Antecedents in blockchain or personal coredoc? (see QUESTION H) - antecedents are still claim statements in the blockchain, but they become antecedents in the claims as they're listed in the coredoc.

Algorithm 4: Coredoc Merge ​

Location: implementation/algorithms/coredoc_merge.py

Requirements:

  • Merge two personal coredocs
  • Identify merge conflicts
  • Questions:
    • Merge conflicts occur when:
      • Same claim has different truth values? yes
      • Same claim has different antecedents? yes
      • Different visibility settings? yes
      • duplicate claims (which one to pick)
    • How to resolve: Manual review? Keep both? Voting? - can't keep both, coredoc cannot have duplicate claims and if each claim is distinct, then it can only have one set of value for the truth etc. Maybe the antecedents can be merged.

Algorithm 5: Linear-to-Atomic Decomposition ​

Location: implementation/algorithms/ (multiple files, different algorithms)

Requirements:

  • Convert paragraph/document into atomic claims
  • Different algorithms with different philosophies
  • Questions:
    • What philosophies? Examples:
      • Logical decomposition (break into logical atoms)
      • Sentence-based (one claim per sentence)
      • Semantic units (break at meaning boundaries)
    • Name the different algorithms: _______________
    • Which is default/recommended?

The goal for the algorithm needs to be to faithfully represent claims in notations that are unambiguous and ensure that a specific piece of information cannot be specified in any other way. We might need to come up with our own system, somewhat akin to our own language for how information is rendered, to facilitate unambiuous representation and 1:1 rerpresentation of the notation with the actual fact through direct references to objects/places/named phenomena.

Algorithm 6: Visibility Cascading ​

Location: implementation/algorithms/visibility_cascade.py

Requirements:

  • Update claim visibility (public ↔ private)
  • Cascade to antecedents and dependents
  • Prevent: Public claim with private antecedent (or vice versa - see QUESTION D)
  • Questions:
    • Cascade direction: Both up and down? Only down?
    • If I make private → public, and antecedent is private, what happens?
      • [ ] Error: Can't make public until antecedent is public
      • [ ] Auto-cascade: Antecedent becomes public too
      • [ ] Warning: Proceed but show dependency issue

I think we should allow people to post public claims about private events that they can selectively share with others whan request access to the private claim. ​

4. Pravada Platform Blueprint ​

Platform Concept ​

Social media platform where members maintain personal coredocs and platform synthesizes public content.

Homepage Visualization ​

"Graphical representation of public claims existing in most coredocs" "World map with heatmap overlay for hotspots where large number of observational claims are being tagged"

Questions:

  1. Heatmap based on:

    • [ ] Number of members who have claim in coredoc (popularity)
    • [x] Number of claims at geographic location (density)
    • [ ] Number of members with truth=true (consensus)
    • [ ] Other: _______________

  2. Click on claim reveals:

    • [x] Claim text + truth value distribution (% true/false/null across members)
    • [ ] Antecedent claims (upstream navigation)
    • [x] Dependent claims (downstream navigation)
    • [ ] Timeline of truth value changes
    • [ ] Geographic distribution

Bidirectional Causal Navigation ​

"View antecedents and claims that have this claim as antecedent" "Bidirectional navigation of causal connections"

UX Requirements:

  • Graph visualization (node-edge diagram)
  • Filtering: Show only claims with truth=true in MY coredoc
  • Depth control: How many levels upstream/downstream to show
  • Highlight: Show where my truth assignments differ from consensus

Questions:

  1. Default view:

    • [x] Show all claims (regardless of truth value)
    • [ ] Show only claims with majority truth=true
    • [ ] Show only claims in my coredoc

  2. Consensus visualization:

    • Show % of members with truth=true/false/null for each claim?
    • Highlight claims with >90% consensus? <60% consensus (controversial)?

Private Coredocs (Paid Feature) ​

"Private claims can only be made by those who pay for pravada account" "Private blockchains for private claims"

Questions:

  1. Private blockchain architecture:
    • [ ] Separate blockchain per user (expensive, isolated)
    • [ ] Shared private blockchain (all paid users, encrypted)
    • [x] Single blockchain, private claims marked/encrypted
    • [ ] Other: _______________

People can request the key for decryption. We might need to maintain distinct keys for each claim, this way they can share the keys to those who wish to see it. 2. Pricing model:

  • Free tier: Public claims only, reference shared blockchain
  • Paid tier: Private claims, separate private blockchain
  • How much? _______________

5. Updated Folder Structure ​

Coredoc/
├── overview.yml                    # Updated with new architecture
├── plan.md                        # This file
│
├── paper/                         # Theoretical paper (pure theory)
│   ├── coredoc_paper.md          # Focus on boolean claims, mental model sync
│   └── figures/
│
├── theory/                        # Core concepts
│   ├── boolean_claims.md         # NEW: Atomic boolean claims with truth values
│   ├── personal_coredoc.md       # NEW: Personal truth assignment model
│   ├── blockchain_architecture.md # NEW: Shared immutable claim statements
│   ├── claims.md                 # Observational vs inferential (updated)
│   ├── objects.md                # Class-Object-Agent-Spacetime
│   └── connectors.md             # THEREFORE connector
│
├── implementation/
│   ├── architecture.md           # System design (updated for new model)
│   ├── pravada_blueprint.md      # NEW: Social platform specification
│   └── algorithms/               # NEW: Python algorithm implementations
│       ├── claim_creation.py
│       ├── truth_value_update.py
│       ├── antecedent_management.py
│       ├── coredoc_merge.py
│       ├── visibility_cascade.py
│       └── decomposition/
│           ├── logical_decomposition.py
│           ├── sentence_based.py
│           └── semantic_units.py
│
├── references/
│   ├── literature_review.md
│   └── litreview/
│
└── archive/
    └── [V2-V5 drafts, old architecture docs]

6. Immediate Action Items ​

Phase 1: Clarify Architecture (Your Input Needed) ​

Answer all questions above (A-H) and algorithm questions

Phase 2: Update Theory Documents ​

  • Rewrite claims.md to reflect boolean nature + truth values
  • Create boolean_claims.md - comprehensive explanation
  • Create personal_coredoc.md - member coredoc model
  • Create blockchain_architecture.md - shared claim statement blockchain

Phase 3: Create Pravada Blueprint ​

  • Full platform specification
  • UX mockups for graph visualization
  • Navigation patterns
  • Privacy model
  • Monetization strategy

Phase 4: Implement Algorithms ​

  • All 6 algorithms in Python
  • Unit tests for validation rules
  • Example coredocs for testing merge conflicts

Phase 5: Update Paper ​

  • Incorporate boolean claim architecture
  • Explain personal truth assignment model
  • Implications for mental model synchronization
  • Remove/update sections that assume immutable truth values

7. Your Responses Required ​

Please answer the following to proceed:

Architecture Questions ​

QUESTION A (Truth Value Semantics):
  1. Can I have truth=false in my coredoc? _______________
  2. Difference between truth=false vs not in coredoc? _______________
  3. Is null temporary or permanent? _______________

QUESTION B (Antecedent Logic):
  - What happens when antecedent becomes false? _______________
  - Cascade direction? _______________

QUESTION C (Observational Truth):
  - Can others set my subjective observations to false? _______________
  - Multiple contradictory objective observations acceptable? _______________

QUESTION D (Visibility Cascading):
  - Must antecedent match visibility? _______________
  - Auto-cascade or manual decision? _______________

QUESTION E (Deduplication):
  - Detection method? _______________
  - "Water temp 23.5C" = "Water temperature 23.5 degrees"? _______________
  - "I observed X" = "John observed X"? _______________

QUESTION F (Nomination):
  - Can accept with truth=false? _______________
  - Author = nominator or blockchain creator? _______________

QUESTION G (Architecture):
  - Blockchain + Personal Coredoc structure correct? _______________

QUESTION H (Antecedents):
  - Where stored: blockchain, personal coredoc, or hybrid? _______________
  - Can different people have different antecedents for same claim? _______________

Algorithm Questions ​

ALGORITHM 1 (Creation):
  - Atomic validation rules? _______________
  - Duplicate detection method? _______________
  - Who can create on blockchain? _______________

ALGORITHM 2 (Truth Update):
  - "Trigger review" means? _______________
  - Cascade up or down? _______________

ALGORITHM 5 (Decomposition):
  - Name the different algorithms: _______________
  - Which is default? _______________

ALGORITHM 6 (Visibility):
  - Cascade direction? _______________
  - Private→Public with private antecedent behavior? _______________

Pravada Platform ​

PLATFORM (Visualization):
  - Heatmap based on? _______________
  - Click reveals? _______________
  - Default view? _______________
  - Consensus visualization approach? _______________

PLATFORM (Privacy):
  - Private blockchain architecture? _______________
  - Pricing model? _______________

Updated: 2026-01-22 based on overview.yml new_notes

Private. Restricted access.