Preamble

Signal Network exists to establish trust infrastructure for high-signal humans in the age of AI. As artificial intelligence makes outputs cheap and abundant, the value of verified human reasoning becomes paramount. This Constitution establishes the principles and structure that govern our network.

Mission

To build documentary infrastructure that preserves the value of human judgment by creating verifiable records of reasoning, predictions, and decisions — proof that matters because it was recorded before outcomes were known.

Core Principles

1. Elevate Signal Over Noise

Prioritize clarity, intention, and divergence. Reject mimicry, entropy, and hollow engagement. Signal is what remains valuable after the hype fades.

2. Protect the Coherence of Thought

Through the Keaton Protocol and ProofLock, preserve the fidelity of high-signal insight across time, translation, and interpretation. Ideas should not drift from their original meaning.

3. Anchor Trust in Verifiable Identity

Enable Signal Passports, Node Registries, and timestamped proofs so status is earned by demonstrated judgment, not popularity or credentials.

4. Empower Those Who Move with Weight

Recognize nodes that carry risk, create value, withstand pressure, or name truth. Reward action and accuracy over appearance and volume.

5. Outlast Systems That Reward Spectacle

While algorithms chase virality, Signal Network records reality. Build memory, not metrics; proof, not impressions; lineage, not likes.

Guiding Values

• Proof over Performance — Trust is earned through verified behaviors, not displays
• Behavior over Belief — What you do matters more than what you claim
• Succession over Centralization — Power distributed, systems that outlast individuals
• Compression over Clout — Value substance, not superficial status
• Divergence over Conformity — Original thinking valued over consensus-chasing

Governance Structure

Origin Nodes

Founding nodes with special governance privileges during network establishment. Cannot be created after launch.

Atlas Nodes

Nodes elevated to governance responsibility through demonstrated commitment, judgment, and community trust.

Standard Nodes

Full participants with all rights except elevated governance privileges.

Observer Nodes

Read-only participants who can view but not create or witness.

Amendment

This Constitution may be amended through the Amendment Procedure, requiring supermajority approval from Atlas Nodes and a community comment period. Core Principles (Section 3) require unanimous Origin Node approval to modify and are candidates for ProofLock post-launch.

Ratification

This Constitution is effective upon publication and acceptance by the founding Origin Node. All nodes joining Signal Network accept this Constitution as a condition of participation.

Purpose

These rights are inalienable. They cannot be suspended, revoked, or overridden by governance action. They define the minimum protections every node receives by participating in Signal Network.

Article I: Right to Privacy

Every node controls their personal data. No information is shared without explicit consent. Private proofs remain private. The network will never sell, trade, or expose user data to third parties without direct user authorization.

Article II: Right to Data Ownership

Nodes own their proofs, their identity data, and their activity history. This data can be exported at any time in open formats. Signal Network is a custodian, not an owner, of user data.

Article III: Right to Transparency

Nodes have the right to understand how their data is used, how SignalRank is calculated, and how governance decisions are made. No hidden algorithms, no secret rules, no undisclosed policies.

Article IV: Right to Due Process

No node may be suspended, terminated, or penalized without documented cause, notice, opportunity to respond, and right to appeal. Emergency suspensions require expedited review.

Article V: Right to Exit

Any node may leave Signal Network at any time, for any reason, with full data export. There are no exit penalties, no lock-in periods, no hostage-taking.

Article VI: Right to Fair Treatment

All nodes are subject to the same rules. No special exemptions for influential nodes, early adopters, or paying customers. Governance applies equally.

Article VII: Right to Participate

Standard nodes and above may create proofs, request witnesses, and participate in community governance. Participation rights cannot be removed without due process.

Article VIII: Right to Accountability

Every governance action is traceable to specific actors. Nodes have the right to know who made decisions affecting them and on what basis.

Article IX: Right to Proof Integrity

Witnessed proofs cannot be modified or deleted by anyone, including the author or network administrators. What is recorded stays recorded.

Article X: Right to Correction

Nodes have the right to publish corrections to their own proofs, clearly linked to the original. Acknowledging error is protected and encouraged.

Enforcement

Violations of these rights may be raised through the Dispute Resolution process. Systemic violations may trigger Emergency Response Protocol. These rights take precedence over all other governance documents except the Constitution's Core Principles.

Purpose

Governance must have boundaries. This document defines the scope of Signal Network governance — what it covers, what it explicitly does not cover, and how scope disputes are resolved.

Within Governance Scope

Network Operations

• Proof submission, validation, and storage rules
• Witness processes and requirements
• SignalRank calculation methodology
• API access and rate limiting

Node Management

• Node creation and verification
• Node types and privileges
• Suspension and termination procedures
• Data portability and deletion

Community Standards

• Code of Conduct
• Dispute resolution
• Recognition and rewards
• Communication guidelines

Governance Itself

• Amendment procedures
• Voting mechanisms
• Role definitions
• Decision frameworks

Outside Governance Scope

Proof Content

Governance does not judge whether proofs are true, wise, or valuable. It only ensures they conform to schema and process requirements. Content quality is measured by SignalRank over time, not governance decree.

External Behavior

What nodes do outside Signal Network is not governed here. We govern network participation, not lives.

Beliefs and Opinions

Governance does not regulate what nodes believe, predict, or argue. Diversity of thought is essential to signal.

Technical Implementation

How the underlying technology works is an engineering decision, not a governance decision, unless it affects user rights or network principles.

Business Operations

Signal Network PBC's corporate decisions (hiring, fundraising, partnerships) are separate from network governance, though they must not violate governance principles.

Scope Disputes

When it's unclear whether something falls within governance scope:

1. Presume outside scope (governance is limited by default)
2. Raise for Atlas Node interpretation
3. If disputed, use Dispute Resolution process
4. Precedent recorded for future reference

Scope Expansion

Governance scope can only be expanded through the Amendment Procedure. Scope cannot be expanded retroactively — new rules apply going forward.

Relationship to Other Documents

This document constrains all other governance documents. No document may regulate matters outside this scope without first amending this document.

Purpose

Clear authority prevents both chaos and tyranny. This document maps decision-making power across the network so everyone knows who can take what actions.

Origin Nodes

Founding nodes with maximum governance authority during network establishment.

Exclusive Powers

• Amend Core Principles (requires unanimity)
• ProofLock protocols
• Appoint initial Atlas Nodes
• Veto constitutional amendments (during establishment phase)

Shared Powers

• All Atlas Node powers
• All Standard Node powers

Sunset

Origin Node exclusive powers phase out as network matures. Timeline defined in Sustainability document.

Atlas Nodes

Elevated governance participants with operational authority.

Powers

• Vote on governance amendments
• Vote on policy changes
• Initiate compliance reviews
• Approve node elevations (to Atlas)
• Emergency suspension authority (with review)
• Interpret ambiguous governance questions

Limitations

• Cannot unilaterally change Constitution
• Cannot modify ProofLocked content
• Cannot override Bill of Rights
• Cannot act without documentation

Selection

Atlas Nodes are elevated through the Atlas Elevation Protocol based on demonstrated commitment, judgment, and community trust.

Standard Nodes

Full participants with fundamental rights and powers.

Powers

• Create proofs
• Request and provide witnessing
• Participate in community discussions
• Vote in community polls (advisory)
• Comment on proposed amendments
• File disputes
• Export data
• Terminate participation

Limitations

• Cannot vote on binding governance decisions
• Cannot initiate compliance actions
• Cannot elevate other nodes

Observer Nodes

Read-only participants.

Powers

• View public proofs
• View public profiles
• Read governance documents

Limitations

• Cannot create proofs
• Cannot witness
• Cannot participate in governance
• Cannot access network-visibility content

Validators

Technical role, not governance role. Validators check proof conformance.

Powers

• Accept or reject proofs based on schema compliance
• Flag suspicious patterns for review

Limitations

• Cannot judge content quality or truth
• Cannot override governance decisions
• Subject to accuracy review

Decision Types by Authority Level

Purpose

Power must be limited. This document defines what Signal Network will never do, regardless of governance votes or operational pressure. These are hard limits.

Data Limits

We Will Never

• Sell user data to third parties
• Share private proofs without explicit consent
• Use personal data for advertising targeting
• Provide data to governments without legal compulsion and user notification (where legal)
• Create shadow profiles of non-users

Content Limits

We Will Never

• Modify witnessed proofs (immutability is absolute)
• Delete proofs to please powerful parties
• Judge proof content for political correctness
• Algorithmically amplify or suppress based on viewpoint
• Require proofs to conform to any ideology

Exception

Content that violates law (e.g., CSAM, direct threats of violence) will be removed with documentation. This is a legal compliance limit, not a content judgment.

Governance Limits

We Will Never

• Suspend or terminate nodes without documented cause and due process
• Create secret governance rules
• Allow any single node (including founders) permanent unchecked power
• Retroactively apply new rules to past behavior
• Override the Bill of Rights through any mechanism

Business Limits

We Will Never

• Optimize for engagement over signal quality
• Create addictive features designed to maximize time-on-site
• Charge for basic rights (export, termination, privacy)
• Allow acquisition by entities whose values conflict with the Constitution
• Abandon the network without 90-day notice and data preservation

Technical Limits

We Will Never

• Use proprietary formats that lock in user data
• Make data export technically impossible or impractical
• Deploy dark patterns to manipulate user choices
• Hide how SignalRank is calculated

Enforcement

These limits are:

• Not subject to amendment through normal procedures
• Enforceable through Dispute Resolution
• Grounds for user exit without penalty if violated
• Public commitments that any node can hold us to

Limit Modification

Adding new limits: Standard Amendment Procedure.

Removing limits: Requires unanimous Origin Node approval + 90-day notice + community supermajority. In practice, these limits should be treated as permanent.

Core Principle

Users control their visibility. Signal Network defaults to privacy and requires explicit choices to share. Transparency is a choice, not an imposition.

Visibility Levels

Public

• Visible to anyone, including non-users
• Indexed by search engines
• Accessible via API
• Cannot be made private once witnessed

Network

• Visible to all authenticated nodes
• Not indexed externally
• Accessible via authenticated API
• Can be elevated to Public

Connected

• Visible only to nodes you've connected with
• Not accessible via API
• Can be elevated to Network or Public

Private

• Visible only to you
• Not accessible to anyone else, including administrators
• Can be elevated to any level
• Truly private — we cannot see it

Visibility Rules

Upward Only

Visibility can be increased (private → public) but never decreased once witnessed. You can share more broadly; you cannot take back what's been seen.

Explicit Choice

Every visibility level requires explicit selection. No defaults that expose more than intended.

Witness Impact

Once a proof is witnessed, its visibility is locked. Witnesses have committed to the proof's existence; hiding it would break integrity.

Profile Privacy

Always Public

• Node ID (your identifier)
• Node type (Standard, Atlas, etc.)
• Public proof count

Configurable

• Display name
• Bio/description
• Domain interests
• Connection list
• Activity history
• SignalRank display

SignalRank Privacy

Your SignalRank is calculated regardless of privacy settings (it's based on your public and network proofs). You control whether it's displayed:

• Show full rank per domain
• Show aggregate only
• Show to connections only
• Hide completely

Hiding your rank may affect how others evaluate your proofs.

Data We Collect

Full transparency on what we store:

• Your proofs (at visibility level you choose)
• Your profile data (as you provide it)
• Your connections (bidirectional consent)
• Activity logs (when you do things, not content)
• Technical data (for security and debugging)

We Do Not Collect

• Browsing behavior outside Signal Network
• Contact lists from your devices
• Location data (unless you add it to proofs)
• Biometric data

Third Party Sharing

We share your data with third parties only:

• When you explicitly authorize (e.g., API integrations you approve)
• When legally compelled (with notification where legal)
• In aggregate, anonymized form for research (no individual identification)

We never sell your data. Period.

The Problem

How do you prove something existed at a specific time without trusting a central authority? Timestamps can be faked. Databases can be modified. Single points of truth become single points of failure — and corruption.

The Solution: Distributed Witnessing

Instead of one authority declaring "this existed at time T," multiple independent nodes attest: "I saw this at time T." Manipulation requires coordinating multiple independent parties — much harder than corrupting one database.

How Witnessing Works

1. Proof Creation

Author creates proof with timestamp.

2. Witness Request

Author requests one or more nodes to witness.

3. Witness Review

Potential witness sees the proof and decides whether to attest.

4. Attestation

Witness signs attestation: "I verify this proof existed at [timestamp]."

5. Record

Witness relationship recorded on both nodes. Witness stores copy of proof.

What Witnesses Attest

• The proof existed at the claimed time
• The author was the stated node
• The content matches what was presented

What Witnesses Do NOT Attest

• The proof content is true
• The prediction will be accurate
• The reasoning is sound
• They agree with the author

Witnessing is about existence and timing, not truth or quality.

Witness Selection

Authors choose their witnesses. Factors to consider:

Independence

Witnesses with no prior relationship to the author carry more weight. Your business partner witnessing your prediction is less convincing than a stranger.

Reputation

High SignalRank witnesses add credibility. They have more to lose by false witnessing.

Domain Relevance

Witnesses who understand the proof's domain can more credibly attest they saw what they claim.

Quantity

More witnesses = more verification. Diminishing returns after 3-5 for most proofs.

Witness Incentives

Positive

• Witnessing high-quality proofs that prove accurate: slight SignalRank boost
• Building reputation as reliable witness
• Network effects — witnesses often get witnessed in return

Negative

• Witnessing proofs that prove fraudulent: SignalRank penalty
• False witnessing: permanent ban
• Your reputation is linked to what you vouch for

Witness Obligations

• Store witnessed proof for minimum 1 year
• Respond to verification requests within 48 hours
• Report any evidence of proof tampering

Verification

Anyone can verify a witnessed proof by:

1. Checking the proof exists on author's node
2. Checking witness attestations exist
3. Requesting witnesses confirm their attestation
4. Comparing proof content across all copies

Any discrepancy triggers investigation.

Without Witnesses

Proofs without witnesses:

• Still valid and recorded
• Less verifiable (only author's word on timing)
• Lower weight in SignalRank calculations
• Can be witnessed later (but attestation reflects when witness saw it, not original timestamp)

The Immutability Principle

Once a proof is witnessed, it cannot be modified or deleted. Not by the author. Not by administrators. Not by anyone. This is not a policy choice — it's fundamental to how Signal Network creates trust.

Why Immutability Matters

Trust Requires Permanence

If predictions could be quietly edited after outcomes are known, the entire system becomes meaningless. Anyone could claim perfect foresight.

Witnesses Rely On It

Witnesses attest to specific content at specific times. Changing the content betrays their attestation.

Accountability Requires Records

The value of Signal Network is the verified record. Erasable records have no value.

What Is Immutable

• Proof content (title, body, all fields)
• Proof metadata (timestamp, author, type)
• Witness attestations
• ProofLocked protocols
• Governance decisions

What Is NOT Immutable

• Draft proofs (before witnessing)
• Private proofs (no witnesses)
• Profile information
• Visibility settings (can increase, not decrease)
• Non-ProofLocked governance documents

Handling Errors

People make mistakes. Predictions fail. Facts turn out to be wrong. Immutability doesn't mean pretending errors don't happen — it means handling them honestly.

The Correction Proof

When you're wrong, publish a Correction proof:

• Links to original proof (backward reference)
• Acknowledges the error explicitly
• Explains what was wrong and why
• Optionally provides updated thinking

The original stays. The correction is added. Both are visible.

Error Types

Factual Error

You stated something false. Correction acknowledges the incorrect claim and provides accurate information.

Prediction Failure

Your prediction didn't come true. Correction documents the outcome and analyzes what you missed.

Reasoning Error

Your logic was flawed. Correction identifies the flaw and shows improved reasoning.

Typo/Minor Error

Small mistakes that don't affect meaning can be noted in a correction, but the original stands.

Correction Incentives

Signal Network rewards honest corrections:

• Timely corrections recover more SignalRank than silent failure
• Detailed analysis of errors shows intellectual honesty
• Correction history is visible — it shows character

The goal is a culture where acknowledging error is respected, not punished.

What About Truly Harmful Content?

Immutability has one narrow exception: content that is illegal (e.g., CSAM, direct incitement to imminent violence). Such content may be removed with:

• Documentation of what was removed and why
• Legal basis cited
• Record that removal occurred (the fact of removal is itself immutable)

This is rare, legally required, and fully documented. It does not extend to merely controversial, offensive, or wrong content.

Living With Your Record

Your Signal Network history is permanent. This should encourage:

• Thoughtfulness before publishing
• Honesty in corrections
• Humility about certainty
• Long-term thinking over short-term performance

The permanent record is a feature, not a bug.

The Scenario

Alex, a technology analyst (node: alex-tech-001), believes that Company X's new AI product will fail to meet its Q2 sales targets. Alex wants to create a verifiable record of this prediction before the results are announced.

The Proof

Proof Metadata

proof-id: pred-2026-0204-ax001
type: Prediction
author-node: alex-tech-001
timestamp: 2026-02-04T14:30:00Z
state: Verified
domain-tags: technology, ai, business, earnings
backward-refs: claim-2026-0115-ax001
constraint-set: standard-prediction
outcome-window: 2026-04-01/2026-04-30
verification-criteria: Company X Q2 earnings report
witness-nodes: jordan-fin-042, sam-tech-088

Proof Content

Title: Company X Q2 AI Product Sales Miss

Summary: I predict Company X's new AI assistant product 
will miss Q2 2026 sales targets by at least 15%.

Body: Based on my analysis of early adoption data, 
competitor positioning, and enterprise feedback, I believe 
Company X has overestimated demand for their AI assistant.

Key factors:
- Enterprise pilots showing 40% lower conversion than projected
- Competitor Y launching similar product at 30% lower price point
- Integration complexity deterring mid-market adoption

I estimate they will report 15-25% below their stated 
$500M Q2 target, likely in the $375-425M range.

This prediction builds on my earlier claim about enterprise 
AI adoption headwinds (ref: claim-2026-0115-ax001).

The Lifecycle

1. Creation (Feb 4, 2026)

Alex drafts the proof, sets visibility to Public, defines outcome window (April 2026), and specifies verification criteria (official earnings report).

2. Witness Request (Feb 4, 2026)

Alex requests witnesses from two nodes in relevant domains: jordan-fin-042 (financial analyst) and sam-tech-088 (tech industry observer).

3. Witnessing (Feb 4-5, 2026)

Both witnesses review the proof, confirm they can see it with the stated content, and sign attestations. Proof state changes from Draft to Verified.

4. Waiting (Feb-Apr 2026)

The proof exists in the network. Anyone can see Alex's prediction. The outcome is not yet known.

5. Outcome (Apr 28, 2026)

Company X announces Q2 results: $390M in AI product sales, 22% below target.

6. Resolution

The prediction is marked as CORRECT. Alex's SignalRank in the technology and business domains increases. The witnesses' ranks also receive small boosts for witnessing an accurate prediction.

If Alex Had Been Wrong

Suppose Company X had exceeded targets with $550M in sales:

Automatic

Prediction marked as INCORRECT. SignalRank adjustment (negative, but modest for a single miss).

Best Practice

Alex publishes a Correction proof:

• Acknowledges the miss
• Analyzes what the original analysis got wrong
• Documents learning for future predictions

The correction partially recovers SignalRank and demonstrates intellectual honesty.

Key Elements Illustrated

Timestamp Integrity

The prediction was recorded and witnessed before the outcome was known. Post-hoc fabrication is impossible.

Verifiable Criteria

The verification criteria (earnings report) is objective and external. No subjective judgment needed.

Backward References

The proof links to earlier analysis, showing reasoning lineage.

Witness Independence

Two independent nodes attest to the proof's existence and timing.

Domain Tagging

Tags enable the proof to affect SignalRank in relevant domains only.

Schema Reference

This proof conforms to Signal HTML Schema v1. See Technical documentation for full schema specification.

Purpose

This manual provides practical guidance for governance participants. It translates constitutional principles into operational procedures.

Governance Rhythm

Daily

• Monitor compliance flags
• Review emergency items
• Process routine approvals

Weekly

• Atlas Node coordination call (optional)
• Review pending disputes
• Assess community feedback

Monthly

• Compliance report review
• SignalRank algorithm review
• Policy effectiveness assessment

Quarterly

• Full governance audit
• Risk assessment update
• Strategic review

Decision Making

Routine Decisions

Day-to-day operational choices within existing policy. Any authorized role can make these without vote.

Examples: Approving standard node applications, processing exports, routine support.

Policy Decisions

Changes to how existing policies are implemented. Requires Atlas Node majority.

Examples: Adjusting rate limits, modifying onboarding flow, updating templates.

Governance Decisions

Changes to governance documents or structures. Requires Atlas Node supermajority + comment period.

Examples: Amending procedures, creating new roles, modifying dispute process.

Constitutional Decisions

Changes to foundational documents. Requires enhanced process per Amendment Procedure.

Documentation Requirements

All governance actions must be documented with:

• What decision was made
• Who made it (node IDs)
• When (timestamp)
• Why (brief rationale)
• Authority (which document/role authorized this)

Undocumented decisions are invalid and reversible.

Communication

Internal (Governance Participants)

• Governance channel for coordination
• Secure communication for sensitive matters
• Shared documentation repository

External (All Nodes)

• Governance announcements for decisions
• Comment periods for proposed changes
• Transparency reports for major actions

Conflict of Interest

Governance participants must:

• Disclose any personal stake in decisions
• Recuse from voting on matters where conflicted
• Document conflicts even if recusal not required

Undisclosed conflicts discovered later void the decision.

Emergency Procedures

When normal procedures are too slow:

1. Any Atlas Node can invoke emergency authority
2. Take immediate protective action
3. Document thoroughly
4. Trigger immediate review by other Atlas Nodes
5. Regularize or reverse within 48 hours

See Emergency Response Protocol for details.

Onboarding Governance Participants

New Atlas Nodes must:

• Read all foundational documents
• Shadow existing Atlas Node for 30 days
• Demonstrate understanding through Q&A
• Accept governance responsibilities formally

Decision Types

Proposal Format

All non-routine decisions require a proposal with:

• Title: Clear, descriptive name
• Type: Policy / Governance / Constitutional
• Proposer: Node ID
• Summary: One paragraph overview
• Problem: What issue this addresses
• Solution: Specific proposed action
• Impact: Who/what is affected
• Alternatives: Other options considered
• Timeline: Implementation schedule

Voting Rules

Quorum

Minimum participation required for valid vote:

• Policy decisions: 50% of Atlas Nodes
• Governance decisions: 67% of Atlas Nodes
• Constitutional decisions: 80% of Atlas Nodes

Thresholds

• Majority: More than 50% of votes cast
• Supermajority: At least 67% of votes cast
• Unanimity: 100% of votes cast

Voting Period

• Policy: 3 days minimum
• Governance: 7 days minimum
• Constitutional: 14 days minimum

Abstention

Abstentions count toward quorum but not toward thresholds. "Present but not voting" is valid.

Comment Periods

Before voting on Governance and Constitutional decisions:

• Proposal published for community review
• All nodes may comment
• Proposer must respond to substantive concerns
• Proposal may be modified based on feedback
• Significant modifications restart comment period

Implementation

After approval:

1. Decision recorded in governance log
2. Affected documents updated
3. Implementation assigned to responsible party
4. Timeline established
5. Completion confirmed and documented

Reversal

Decisions can be reversed through:

• Same process that created them (new proposal, vote)
• Successful dispute resolution
• Emergency action (with review)

Reversals are documented as thoroughly as original decisions.

Precedent

Past decisions guide future ones:

• Similar situations should be handled similarly
• Departing from precedent requires explanation
• Precedent library maintained for reference

Precedent informs but does not bind — circumstances may differ.

What is a Node?

A node is a verified participant in Signal Network. Each node represents one identity — human or organization — that has agreed to participate under network governance.

Node Rights

All nodes in good standing have the right to:

• Create proofs according to their node type
• Control visibility of their content
• Export their data at any time
• Terminate participation voluntarily
• Due process before adverse action
• Appeal governance decisions
• Access governance documents
• Provide feedback on proposals

See Bill of Rights for complete enumeration.

Node Responsibilities

By participating, nodes agree to:

• Abide by the Constitution and governance documents
• Follow the Code of Conduct
• Represent their identity honestly
• Not manipulate network mechanisms
• Honor witnessing commitments
• Respect other nodes' rights
• Report violations they observe

Node Types

Observer Node

Entry-level participation.

• Can view public content
• Cannot create proofs
• Cannot witness
• Useful for evaluation before full participation

Standard Node

Full participant.

• All Observer capabilities
• Can create proofs
• Can witness
• Can participate in community governance
• Earns and displays SignalRank

Atlas Node

Governance participant.

• All Standard capabilities
• Voting rights on governance decisions
• Can initiate compliance reviews
• Emergency action authority
• Additional responsibilities (see Roles document)

Origin Node

Founding node with special authority during network establishment.

• All Atlas capabilities
• ProofLock authority
• Constitutional veto (establishment phase)
• Cannot be created after launch

Good Standing

A node is in good standing if:

• No unresolved compliance violations
• No active suspension
• Identity verification current
• Accepted current governance terms

Nodes not in good standing may have restricted capabilities until issues are resolved.

Node Lifecycle

Creation

New nodes created through Onboarding process. Requires identity verification and governance acceptance.

Active

Normal participation state. Full rights per node type.

Suspended

Temporary restriction due to compliance issue. Rights limited pending resolution.

Dormant

Inactive but not terminated. Profile preserved, no activity required.

Terminated

Permanently withdrawn. See Node Termination document.

Multi-Node Rules

• One person/entity may have multiple nodes if disclosed
• Nodes must not be used to manipulate (e.g., self-witnessing)
• Organizations may have designated nodes for different purposes
• Undisclosed multi-node manipulation is a violation

Types of Disputes

Node vs Node

Conflicts between participants: false witnessing claims, harassment, impersonation.

Node vs Governance

Challenges to governance decisions: unfair suspension, improper process, rights violations.

Interpretation

Disagreements about what governance documents mean or require.

Compliance

Allegations of rule violations.

Resolution Principles

• Fair hearing: All parties can present their case
• Impartiality: Deciders have no stake in outcome
• Transparency: Process and reasoning documented
• Proportionality: Response matches severity
• Timeliness: Resolution within defined periods

Resolution Process

Level 1: Direct Resolution

Parties attempt to resolve directly.

• Timeline: 7 days
• If resolved: Document agreement, close
• If unresolved: Escalate to Level 2

Level 2: Mediation

Neutral Atlas Node facilitates resolution.

• Mediator assigned within 3 days
• Mediation period: 14 days
• Mediator proposes solution
• If accepted: Document, close
• If rejected: Escalate to Level 3

Level 3: Panel Review

Three Atlas Nodes (no conflicts of interest) review and decide.

• Panel convened within 7 days
• Both parties submit written statements
• Panel may request additional information
• Decision within 21 days
• Decision is binding (subject to appeal)

Level 4: Appeal

Challenge to Panel decision.

• Must be filed within 14 days
• New panel (different Atlas Nodes) reviews
• Appeal limited to process errors or new evidence
• Appeal decision is final

Filing a Dispute

Submit through governance interface or email to [email protected]:

• Your node ID
• Other party (if applicable)
• Type of dispute
• Summary of issue
• What resolution you seek
• Supporting evidence

Interim Measures

During dispute resolution, the panel may:

• Suspend challenged action pending review
• Impose temporary restrictions on parties
• Preserve evidence
• Protect complainant from retaliation

Remedies

Possible outcomes include:

• Dismissal (dispute not valid)
• Warning (violation confirmed, no action)
• Correction (require specific action)
• Reversal (undo challenged decision)
• Compensation (restore lost rank, if applicable)
• Sanction (penalties for violator)
• Policy change (if systemic issue identified)

Confidentiality

• Dispute existence: Confidential during process
• Resolution: Published (anonymized if appropriate)
• Precedent: Decisions become reference for future disputes

Retaliation

Retaliation against disp

Amendment Hierarchy

Different documents have different amendment requirements:

Amendment Process

1. Proposal

Any Atlas Node may propose an amendment:

• Specific text changes (show current vs proposed)
• Rationale for change
• Impact assessment
• Implementation plan

2. Comment Period

Proposal published for community review:

• All nodes may comment
• Proposer responds to substantive concerns
• Duration per document type (14-90 days)

3. Revision

Based on feedback, proposer may:

• Proceed unchanged
• Modify proposal (may restart comment period)
• Withdraw proposal

4. Vote

• Voting period: 7-14 days
• Threshold per document type
• Quorum requirements must be met

5. Implementation

If approved:

• Document updated with clear change markers
• Version number incremented
• Changelog updated
• Announcement published
• Effective date (may be delayed for significant changes)

Emergency Amendments

In urgent situations:

• Any Atlas Node may propose emergency amendment
• Requires 75% Atlas approval within 48 hours
• Effective immediately upon approval
• Must be ratified through normal process within 30 days
• If not ratified, amendment automatically expires

Emergency amendments cannot modify Constitution or Bill of Rights.

Retroactivity

Amendments are never retroactive:

• New rules apply to future actions only
• Past behavior judged by rules in effect at the time
• Ongoing situations transition under new rules going forward

Amendment Records

All amendments permanently recorded:

• Original text
• New text
• Proposer
• Vote record
• Effective date
• Rationale summary

Complete amendment history accessible to all nodes.

Amendment Limits

Some changes cannot be made through amendment:

• Removing Bill of Rights protections entirely
• Making amendments impossible
• Retroactive punishment
• Eliminating due process

These require network reconstitution, not amendment.

What Constitutes an Emergency

Security Emergencies

• Active data breach or attack
• Discovered vulnerability under exploitation
• Compromised credentials affecting network integrity

Integrity Emergencies

• Coordinated manipulation discovered
• False witnessing ring identified
• Proof tampering detected

Safety Emergencies

• Credible threats against nodes
• Illegal content requiring immediate removal
• Doxxing or harassment campaigns

Operational Emergencies

• Critical system failure
• Key person incapacitation
• Legal action requiring immediate response

Emergency Authority

During an emergency, any Atlas Node may:

• Suspend nodes without prior hearing
• Disable features network-wide
• Restrict access temporarily
• Take protective technical measures
• Communicate on behalf of governance

These powers are temporary and subject to immediate review.

Emergency Process

1. Declaration (Immediate)

• Any Atlas Node identifies emergency
• Documents initial assessment
• Notifies other Atlas Nodes
• Invokes emergency authority

2. Immediate Response (0-4 hours)

• Protective measures implemented
• Ongoing harm stopped
• Evidence preserved
• Affected parties notified where possible

3. Assessment (4-24 hours)

• Full scope determined
• Root cause identified
• Damage assessed
• Response plan developed

4. Review (24-48 hours)

• Other Atlas Nodes review actions
• Confirm or modify emergency measures
• Determine if emergency continues
• Begin transition to normal process

5. Resolution (48+ hours)

• Emergency measures regularized or lifted
• Affected parties given due process
• Post-incident review conducted
• Lessons documented

Communication

During Emergency

• Status updates every 4 hours minimum
• Clear designation of spokesperson
• Honest about known and unknown

After Emergency

• Full incident report published
• What happened, why, how responded
• What changes result

Limits on Emergency Power

Even in emergencies, governance cannot:

• Modify witnessed proofs
• Permanently terminate without due process
• Suspend Bill of Rights protections
• Act for personal benefit
• Extend emergency beyond actual need

Emergency Abuse

Misuse of emergency authority is a serious violation:

• False emergency declaration
• Excessive response to minor issue
• Using emergency for personal agenda
• Failing to submit to review

Abuse grounds for Atlas status removal.

Preparation

To enable effective emergency response:

• Contact information current for all Atlas Nodes
• Backup communication channels established
• Emergency procedures reviewed quarterly
• Incident response drills annually

Governance Roles

Origin Node

Current: node001 (Mike Torriero)

Responsibilities:

• Final authority on constitutional matters during establishment
• ProofLock decisions
• Initial Atlas Node appointments
• Network direction and vision
• External representation

Accountability: Public record of all decisions. Subject to Constitution.

Atlas Node

Responsibilities:

• Vote on governance matters
• Review compliance issues
• Participate in dispute resolution
• Emergency response authority
• Community guidance

Time Commitment: ~5 hours/week minimum

Accountability: Voting record public. Subject to removal for inactivity or violation.

Operational Roles

Validator

Responsibilities:

• Check proof conformance to schema
• Verify timestamp validity
• Flag suspicious patterns
• Maintain validation logs

Requirements: 6+ months participation, training certification, good standing

Accountability: Accuracy tracked. Repeated errors lead to status review.

Mediator

Responsibilities:

• Facilitate Level 2 dispute resolution
• Remain neutral between parties
• Propose fair solutions
• Document mediation process

Requirements: Atlas Node status, no conflict with dispute parties

Compliance Reviewer

Responsibilities:

• Investigate potential violations
• Document findings
• Recommend actions
• Track resolution

Requirements: Atlas Node status, compliance training

Advisory Roles

Domain Expert

Responsibilities:

• Advise on domain-specific matters
• Help evaluate proof quality in specialty
• Contribute to domain tag taxonomy

Requirements: Demonstrated expertise (SignalRank in domain)

Authority: Advisory only, no governance power

Technical Advisor

Responsibilities:

• Advise on technical decisions
• Review technical governance implications
• Help evaluate technical risks

Requirements: Technical expertise, appointed by Atlas Nodes

Authority: Advisory only, no governance power

Role Assignment

Atlas Nodes

Elevated through Atlas Elevation Protocol based on demonstrated commitment and community trust.

Operational Roles

Assigned by Atlas Node consensus based on qualifications and availability.

Advisory Roles

Invited by governance based on demonstrated expertise. No formal application.

Role Transitions

Adding Roles

Nodes may hold multiple roles if qualified and no conflict exists.

Stepping Down

Any role can be relinquished with 30-day notice (except emergency).

Removal

Roles can be removed for:

• Inactivity (specific thresholds per role)
• Violation of role responsibilities
• Conflict of interest not disclosed
• Loss of good standing

Removal requires Atlas majority vote with documented cause.

Compensation

Currently all roles are volunteer. Future compensation structure may be developed as network matures. Any compensation will be transparent and governance-approved.

Community Philosophy

Signal Network values substance over noise. Our community interactions should reflect the same principle: quality engagement that creates value, not volume that creates clutter.

Constructive Engagement

When Creating Proofs

• Be specific: Vague predictions are worthless. Define clear outcomes.
• Show reasoning: The "why" matters as much as the "what."
• Set verifiable criteria: How will we know if you're right?
• Acknowledge uncertainty: Confidence without certainty is dishonest.

When Witnessing

• Witness thoughtfully: Your reputation links to what you vouch for.
• Decline when appropriate: It's okay to say no.
• Honor commitments: If you witness, fulfill the obligations.

When Commenting

• Add value: If your comment doesn't contribute, reconsider posting.
• Engage the argument: Respond to reasoning, not personality.
• Be concise: Make your point and move on.

Feedback Culture

Signal Network encourages honest feedback:

• Give feedback constructively: Aim to improve, not to attack.
• Receive feedback gracefully: Criticism of ideas isn't personal attack.
• Distinguish disagreement from disrespect: You can challenge ideas respectfully.

Governance Participation

Comment Periods

• Read proposals before commenting
• Focus on substantive concerns
• Suggest improvements, not just objections
• Respect that not all feedback will be incorporated

Community Polls

• Vote based on network interest, not personal preference
• Polls are advisory — take them seriously but understand limits

Disagreement

Disagreement is valuable — it surfaces different perspectives. Handle disagreement well:

• Assume good faith: Most people aren't malicious, just different.
• Steelman: Engage the strongest version of opposing arguments.
• Accept impasse: Not every disagreement resolves. That's okay.
• Don't escalate: If discussion becomes unproductive, step back.

What to Avoid

• Volume over value: Posting frequently without substance
• Pile-ons: Joining criticism just because others are
• Bad faith: Arguing to win rather than to understand
• Harassment: Repeated unwanted contact or criticism
• Drama creation: Manufacturing conflict for attention

Reporting Issues

If you observe problematic behavior:

• Document what you observed
• Report through governance channels
• Don't engage in public confrontation
• Let governance process handle it

Purpose

This Code establishes minimum standards for participation. It protects the community while preserving freedom of thought and expression.

Core Standards

Honesty

• Represent your identity truthfully
• Don't fabricate or backdate proofs
• Acknowledge errors rather than hiding them
• Don't misrepresent others' positions

Integrity

• Honor witnessing commitments
• Don't manipulate network mechanisms
• Disclose conflicts of interest
• Keep private information private

Respect

• Engage ideas, not identities
• Don't harass or stalk
• Respect others' privacy choices
• Accept that others may disagree

Prohibited Behavior

Zero Tolerance

Immediate suspension, likely termination:

• False witnessing (attesting to proofs that didn't exist)
• Coordinated manipulation schemes
• Illegal content (as defined by applicable law)
• Threats of violence
• Doxxing (revealing private information without consent)

Serious Violations

Investigation and likely sanction:

• Harassment (repeated unwanted contact)
• Impersonation of other nodes
• Undisclosed manipulation (self-witnessing, sock puppets)
• Retaliation against reporters
• Abuse of governance authority

Minor Violations

Warning and correction:

• Uncivil behavior
• Spam or low-quality volume posting
• Minor misrepresentation
• Failure to disclose minor conflicts

What This Code Does NOT Prohibit

• Controversial opinions
• Wrong predictions
• Minority viewpoints
• Criticism of ideas, people, or organizations
• Disagreement with governance
• Leaving the network

Signal Network does not police thoughts or viewpoints — only behaviors that harm the network or its participants.

Confidentiality

• Reporter identity protected where possible
• Investigation details confidential during process
• Outcomes published (may be anonymized)

Updates

This Code

Philosophy

Signal Network rewards signal, not noise. Recognition goes to demonstrated judgment, intellectual honesty, and genuine contribution — not volume, popularity, or gaming.

SignalRank

The primary recognition mechanism. SignalRank reflects:

• Prediction accuracy over time
• Quality of reasoning
• Honest correction of errors
• Valuable witnessing
• Consistency and coherence

SignalRank is earned, not assigned. It cannot be purchased, transferred, or granted by governance.

Badges

Visual recognition for specific achievements:

Participation Badges

• First Proof: Created first verified proof
• First Witness: Provided first witness attestation
• First Correction: Published first honest correction

Milestone Badges

• Verified 10/50/100: Proof count milestones
• Witness 10/50/100: Witnessing count milestones
• Year One/Two/Three: Longevity milestones

Quality Badges

• Sharp Eye: High prediction accuracy rate
• Truth Teller: Pattern of honest corrections
• Trusted Witness: Witnessed proofs that proved accurate

Role Badges

• Validator: Active validator role
• Atlas: Atlas Node status
• Origin: Founding node

Featured Recognition

Periodic highlighting of exceptional contributions:

Proof of the Week

Community-nominated proofs that demonstrate excellent reasoning, specificity, or courage.

Correction Spotlight

Highlighting nodes who handled being wrong with exceptional honesty and insight.

Newcomer Welcome

Recognizing new nodes who contribute quality from the start.

Role Opportunities

High-signal nodes may be invited to:

• Validator role
• Domain expert advisory
• Atlas Node elevation consideration
• Featured contributor status

What We Don't Reward

• Volume: More proofs ≠ more recognition
• Popularity: Follower count is irrelevant
• Engagement: Comments and reactions don't boost rank
• Marketing: Self-promotion doesn't increase standing

Future Considerations

As the network matures, additional recognition may include:

• Governance compensation for Atlas Nodes
• Revenue sharing for high-value contributors
• External partnership opportunities
• Speaking/writing opportunities

Any monetary recognition will be transparent and governance-approved.

Gaming Prevention

Recognition systems are monitored for manipulation:

• Artificial badge hunting detected and badges removed
• Coordinated nomination rings identified
• Quality metrics adjusted if gaming discovered

The goal is recognizing genuine contribution, not optimizable metrics.

Purpose

This document establishes the audit and compliance framework that ensures Signal Network governance remains accountable, transparent, and aligned with its constitutional principles.

Audit Authority

• Internal Audits: Conducted quarterly by designated Atlas Nodes with audit privileges.
• External Audits: Annual third-party review of governance decisions, proof integrity, and financial operations.
• Community Audits: Any node may request a governance audit via the Dispute Resolution process.

Compliance Domains

1. Proof Integrity

All proofs must conform to Signal HTML Schema v1. Non-conforming proofs are flagged and excluded from SignalRank calculations until corrected.

2. Privacy Compliance

Data handling must comply with the Privacy & Visibility Model. User data is never sold, shared, or exposed without explicit consent.

3. Governance Compliance

All governance decisions must follow the Decision Framework. Decisions made outside this framework are invalid and subject to reversal.

4. Protocol Compliance

ProofLocked protocols are immutable. Any modification attempt triggers an automatic compliance violation.

Violation Handling

Audit Trail Requirements

All governance actions must be recorded in the SignalLedger with:

• Timestamp (UTC, ISO 8601)
• Actor node ID
• Action type
• Affected entities
• Justification reference

Reporting

Quarterly compliance reports are published to all nodes. Annual reports are made public at signalnetwork.ai/transparency.

Purpose

Signal Network operates in a high-stakes environment where trust is the primary asset. This document establishes protocols for protecting that trust through proactive risk management.

Risk Categories

1. Proof Integrity Risks

• Fabricated or manipulated proofs
• Timestamp tampering
• Identity spoofing
• Coordinated false witnessing

2. Governance Risks

• Concentration of authority
• Decision capture by bad actors
• Protocol drift from constitutional principles
• Founder dependency (single point of failure)

3. Technical Risks

• Data loss or corruption
• System downtime
• Security breaches
• Dependency failures (external services)

4. Reputation Risks

• Association with bad actors
• Misuse of platform for harmful purposes
• Public relations incidents

Risk Assessment Matrix

Mitigation Strategies

Redundancy

Critical data and systems have multiple backups. No single point of failure for proof storage.

Decentralization

Authority is distributed across nodes. No single node can unilaterally modify governance.

Transparency

All governance decisions are public and auditable, reducing opportunity for hidden manipulation.

Succession Planning

Atlas Node succession protocols ensure continuity if key participants become unavailable.

Incident Response

When a risk materializes:

1. Detect: Identify the incident through monitoring or report
2. Contain: Limit immediate damage
3. Assess: Determine scope and severity
4. Remediate: Fix the underlying issue
5. Review: Document lessons learned and update protocols

Review Cycle

Risk assessment is conducted quarterly. Major incidents trigger immediate review regardless of cycle.

Core Principle

Signal Network does not hold users hostage. Your proofs, your identity, your data — they belong to you. This document codifies that principle into enforceable rights.

Export Rights

What You Can Export

• All Proofs: Complete proof history in Signal HTML Schema v1 format
• Profile Data: Node identity, metadata, preferences
• Witness Records: All witnessing activity (given and received)
• SignalRank History: Historical rank calculations and factors
• Connection Graph: Your network relationships (your connections only)

Export Formats

• JSON (machine-readable, recommended for migration)
• HTML (human-readable archive)
• CSV (tabular data like activity logs)

Export Process

1. Request export via Node Dashboard or API
2. System generates export package (typically within 24 hours)
3. Download link sent to verified contact method
4. Link valid for 7 days

No approval required. Export is a right, not a privilege.

Deletion Rights

What Can Be Deleted

• Profile data and preferences
• Draft proofs (not yet witnessed)
• Private proofs (visibility: self only)

What Cannot Be Deleted

• ProofLocked content: Immutable by design
• Witnessed proofs: Other nodes have verified copies
• Governance actions: Accountability requires permanence

This limitation exists because Signal Network is a trust infrastructure. Once you've made public, witnessed claims, erasing them would undermine the network's integrity.

Account Termination

Users may terminate their node at any time. Upon termination:

• Profile is deactivated (not publicly visible)
• Proofs remain in the network (attributed to terminated node)
• Export package auto-generated and delivered
• Node ID reserved (cannot be reused by others)

See Node Termination document for full procedure.

Migration Support

Signal Network commits to supporting data migration to successor systems or compatible networks. If Signal Network ever shuts down:

• 90-day notice minimum
• Export tools remain functional throughout notice period
• Data preserved in public archive if no successor exists

Core Thesis

Outputs are cheap. Process is scarce.

As AI systems become capable of generating any output on demand, the differentiating value shifts from what was produced to how and why it was produced. Proof-of-Mind captures the reasoning process, not just the conclusion.

The Problem

In a world of infinite AI-generated content:

• Any claim can be fabricated
• Any prediction can be generated post-hoc
• Any expertise can be simulated
• Trust becomes impossible to establish

Traditional credentials (degrees, titles, followers) become meaningless when AI can simulate expertise. Signal Network solves this by documenting the reasoning process before outcomes are known.

The Solution

Proof-of-Mind creates verifiable records of human cognition:

Timestamped Commitment

Proofs are recorded before outcomes, making post-hoc fabrication impossible.

Process Documentation

Not just "what you concluded" but "how you reasoned" — the constraints, uncertainties, and tradeoffs you navigated.

Witnessed Verification

Other nodes attest to the existence and timing of proofs, creating distributed verification.

Outcome Tracking

When predictions resolve, the network records accuracy — building reputation from demonstrated judgment, not claimed expertise.

Six Proof Types

What Proof-of-Mind Is NOT

• Not a blockchain: We don't need distributed consensus for every proof
• Not a prediction market: No betting, no financial incentives for accuracy
• Not social media: Proofs are documentation, not performance
• Not AI-generated: Proofs must be human-initiated (AI may assist drafting, human must commit)

Implementation

Proofs are stored in Signal HTML Schema v1 format with required fields:

• Unique proof ID
• Proof type
• Author node
• UTC timestamp
• State (Draft/Verified/ProofLocked)
• Domain tags
• Backward references (proof lineage)
• Constraint set (active rules)

Why This Matters

Signal Network is building the documentary infrastructure for human cognition. When AI can generate anything, the only remaining signal is the verified record of human judgment over time. Proof-of-Mind is how we preserve that signal.

Purpose

SignalRank quantifies trust based on demonstrated judgment over time. Unlike follower counts or engagement metrics, SignalRank cannot be gamed through volume — it rewards accuracy, consistency, and intellectual honesty.

Core Formula

SignalRank = (Time × Coherence × Cost) ÷ (Hype × Optimization × Extraction)

Numerator (Signal Factors)

• Time: Duration of consistent behavior. Longer track records carry more weight.
• Coherence: Internal consistency of reasoning across proofs. Contradictions reduce score.
• Cost: Skin in the game. Predictions with real stakes matter more than risk-free claims.

Denominator (Noise Factors)

• Hype: Trend-chasing behavior. Following popular narratives reduces signal.
• Optimization: Gaming behavior. Suspicious patterns (timing, hedging) trigger penalties.
• Extraction: Taking value without contributing. Pure consumption lowers rank.

Domain-Specific Ranking

SignalRank is calculated per domain. A node may have:

• High rank in "technology/ai"
• Medium rank in "finance/crypto"
• No rank in "sports" (insufficient proofs)

This prevents reputation transfer — expertise in one area doesn't grant authority in another.

Calculation Inputs

Prediction Accuracy

For predictions with defined outcome windows:

• Correct prediction: +signal
• Incorrect prediction: -signal (smaller penalty if reasoning was sound)
• Acknowledged correction: partial recovery

Witness Quality

Nodes that witness high-quality proofs gain signal. Nodes that witness low-quality or fraudulent proofs lose signal. Choose your witnesses carefully.

Consistency Over Time

Stable, coherent behavior over years outweighs bursts of activity. SignalRank has long memory.

Correction Behavior

Nodes that acknowledge and document errors recover faster than those who quietly abandon wrong predictions.

Anti-Gaming Measures

Volume Immunity

Making more proofs doesn't increase rank. Only accuracy-weighted proofs count.

Hedge Detection

Making contradictory predictions to guarantee one is "right" triggers severe penalties.

Timing Analysis

Proofs made suspiciously close to outcome revelation receive reduced weight.

Network Analysis

Coordinated witness rings are detected and penalized.

Visibility

SignalRank is:

• Public: Anyone can see a node's rank per domain
• Auditable: The inputs to rank calculation are visible
• Historical: Past ranks are preserved, showing trajectory

Limitations

SignalRank is a tool, not a truth oracle. It measures documented behavior within Signal Network. It does not:

• Measure real-world expertise outside the network
• Guarantee future accuracy
• Replace human judgment about trustworthiness

Core Principle

A node is not an "account" granted by Signal Network. A node is a sovereign identity that chooses to participate in the network. The network serves nodes; nodes do not serve the network.

Sovereign Rights

Identity Ownership

Your node ID belongs to you. Signal Network cannot reassign, revoke, or modify your identity without your consent or due process under governance rules you agreed to.

Data Ownership

All proofs, metadata, and activity generated by your node belong to you. See Data Portability for export rights.

Participation Choice

You choose your level of engagement:

• Active: Creating proofs, witnessing, participating in governance
• Passive: Observing, consuming, minimal interaction
• Dormant: Inactive but identity preserved
• Terminated: Withdrawn from network (see Node Termination)

Visibility Control

You control what others see:

• Public proofs: Visible to all
• Network proofs: Visible to connected nodes
• Private proofs: Visible only to you

Node Types

Origin Nodes

Founding nodes with special governance privileges. Cannot be created after network launch.

Atlas Nodes

Nodes with elevated governance responsibilities. Earned through demonstrated commitment and community trust.

Standard Nodes

Full participants with all rights except elevated governance privileges.

Observer Nodes

Read-only participants. Can view public content but cannot create proofs or witness.

Sovereignty Limits

Node sovereignty is not absolute. It operates within the governance framework:

What You Cannot Do

• Modify or delete witnessed proofs (integrity requirement)
• Impersonate other nodes
• Violate the Code of Conduct
• Unilaterally change governance rules

What Can Happen To You

• Suspension for governance violations (with due process)
• SignalRank reduction for bad behavior
• Termination for severe violations (see Node Termination)

All adverse actions require documented justification and appeal rights.

Inter-Node Relations

Nodes interact as sovereign peers:

• No hierarchy: No node commands another (governance roles grant process authority, not personal authority)
• Mutual consent: Witnessing and connections require agreement from both parties
• Reputation independence: Your SignalRank is yours; others cannot directly modify it

Network Exit

Sovereignty includes the right to leave. Any node may terminate participation at any time without penalty beyond losing network access. See Node Termination for procedure.

What is a Validator?

Validators are nodes that verify proof conformance, timestamp integrity, and schema compliance. They ensure proofs meet Signal Network standards before entering the permanent record.

Validator Responsibilities

Schema Validation

Confirm all proofs conform to Signal HTML Schema v1:

• Required fields present (proof-id, type, author-node, timestamp, state, domain-tags, backward-refs, constraint-set)
• Field formats correct (ISO 8601 timestamps, valid node IDs)
• Proof type matches content structure

Timestamp Verification

Ensure timestamps are:

• Valid UTC ISO 8601 format
• Not in the future
• Consistent with proof chain (not before referenced proofs)

Identity Verification

Confirm author-node exists and has valid standing in the network.

Reference Integrity

Verify backward-refs point to existing proofs.

Validator Requirements

Technical Requirements

• Maintain 99% uptime for validation services
• Process validation requests within 60 seconds
• Store validation logs for minimum 1 year

Governance Requirements

• Minimum 6 months network participation
• SignalRank above network median in at least one domain
• No unresolved compliance violations
• Completed validator training certification

Validation Process

1. Submission: Proof submitted to validation queue
2. Assignment: Validator selected (round-robin or availability-based)
3. Check: Validator runs conformance checks
4. Result: VALID, INVALID (with specific failures), or PENDING (needs human review)
5. Record: Validation result logged with validator ID and timestamp

Validation Failures

Validator Accountability

Performance Tracking

Validator accuracy and speed are tracked. Consistently poor performance results in validator status review.

False Validations

Validating non-conforming proofs as valid triggers:

• First offense: Warning + retraining
• Second offense: Temporary suspension
• Third offense: Permanent validator status revocation

False Rejections

Incorrectly rejecting valid proofs triggers review. Pattern of false rejections results in status review.

Validator Compensation

Validators receive recognition through:

• Validator badge on node profile
• Priority consideration for Atlas Node elevation
• Future: Potential fee share from premium validation services

What is Witnessing?

Witnessing is the act of attesting that a proof existed at a specific time. Witnesses don't validate content truth — they verify existence and timing. A witness says "I saw this proof at this time" not "this proof is correct."

Why Witnessing Matters

Witnessing creates distributed verification:

• Timestamp integrity: Multiple witnesses make timestamp manipulation detectable
• Proof persistence: Witnessed proofs have copies across multiple nodes
• Accountability: Claims can't be quietly deleted or modified

Witness Requirements

Eligibility

• Active node in good standing
• No current compliance violations
• Minimum 30 days network participation

Obligations

• Store witnessed proof for minimum 1 year
• Respond to verification requests within 48 hours
• Report if witnessed proof is later modified (violation)

Witnessing Process

1. Request: Proof author requests witness(es)
2. Review: Potential witness views proof
3. Decision: Accept or decline witnessing
4. Attestation: If accepted, witness signs attestation with timestamp
5. Record: Witness relationship recorded on both nodes

Witness Selection

Authors choose their witnesses. Consider:

• Independence: Witnesses with no relationship to author carry more weight
• Reputation: High SignalRank witnesses add credibility
• Domain relevance: Witnesses with expertise in proof domain are more valuable
• Quantity: More witnesses = more verification (diminishing returns after 3-5)

Witness Accountability

False Witnessing

Attesting to proofs that didn't exist at claimed time:

• Severe violation
• Immediate suspension pending investigation
• If confirmed: permanent ban + public record

Coordinated Witness Rings

Groups that witness each other's proofs without genuine verification:

• Detected through network analysis
• All participants penalized
• Witnessed proofs marked as suspect

Witness Negligence

Failing to store or respond to verification requests:

• First offense: Warning
• Repeated: Witness privileges suspended

Declining to Witness

Nodes may decline witness requests for any reason. Common valid reasons:

• Lack of capacity to store additional proofs
• No relationship with requesting node
• Proof content outside area of understanding
• Concerns about proof quality or intent

Declining has no penalty. Witnessing is voluntary.

Witness Compensation

Witnessing is currently uncompensated beyond reputation effects:

• Witnessing high-quality proofs that prove accurate: slight SignalRank boost
• Witnessing low-quality proofs that prove false: slight SignalRank penalty

Choose what you witness carefully — your reputation is linked to theirs.

Overview

The Signal Network API provides programmatic access to public proofs, node information, and network statistics. These terms govern all API usage.

Access Tiers

Public API (Free)

• Read-only access to public proofs
• Basic node information (public profiles)
• Network statistics
• Rate limit: 100 requests/hour

Node API (Authenticated)

• All Public API access
• Create proofs on behalf of authenticated node
• Access node's own private data
• Witness management
• Rate limit: 1,000 requests/hour

Enterprise API (Licensed)

• All Node API access
• Bulk data access
• Webhook integrations
• Priority support
• Custom rate limits

Permitted Uses

• Building applications that display Signal Network data
• Integrating proof submission into external workflows
• Research and analysis (with attribution)
• Personal automation and tooling

Prohibited Uses

• Scraping beyond rate limits: Circumventing rate limits is a violation
• Data resale: Selling raw API data without license
• Impersonation: Creating proofs that misrepresent authorship
• Spam: Automated creation of low-quality proofs
• Attack: Using API to probe for vulnerabilities or disrupt service
• Privacy violation: Aggregating data to deanonymize users

Authentication

Node API and Enterprise API require authentication:

• API keys issued per node
• Keys can be revoked at any time by node owner
• Keys must not be shared or published
• Compromised keys should be reported immediately

Rate Limiting

Rate limits protect network stability:

• Limits reset hourly
• 429 response indicates limit reached
• Retry-After header indicates wait time
• Persistent limit violation results in temporary ban

Data Accuracy

Signal Network provides API data "as is":

• We ensure data matches what's in the network
• We do not guarantee proof content is truthful
• SignalRank is informational, not a guarantee of trustworthiness

Availability

We target 99.9% API availability but do not guarantee uptime. Planned maintenance will be announced 48 hours in advance when possible.

Changes to Terms

API terms may change with 30 days notice. Breaking API changes will be versioned, with deprecated versions supported for minimum 90 days.

Termination

API access may be terminated for:

• Terms violation
• Node termination
• Non-payment (Enterprise tier)
• Legal requirement

Terminated access may be appealed through standard Dispute Resolution.

Philosophy

Signal Network is not a walled garden. Proofs gain value through portability and verification across systems. We prioritize open standards and interoperability over lock-in.

Data Standards

Signal HTML Schema v1

The canonical proof format. External systems should:

• Accept Signal HTML Schema for proof import
• Export proofs in Signal HTML Schema format
• Preserve all required fields during transformation

JSON Export

For programmatic integration:

{
  "proof_id": "string",
  "type": "Prediction|Decision|Claim|Correction|Contribution|Witness",
  "author_node": "string",
  "timestamp": "ISO 8601 UTC",
  "state": "Draft|Verified|ProofLocked",
  "domain_tags": ["string"],
  "backward_refs": ["proof_id"],
  "constraint_set": ["string"],
  "content": {
    "title": "string",
    "summary": "string",
    "body": "string"
  }
}

External System Integration

Supported Integrations

• Git repositories: Proofs linked to commits
• Document systems: Proof metadata embedded in docs
• Calendar systems: Prediction outcome windows synced
• Identity providers: Node identity verification

Integration Requirements

• Must preserve proof integrity (no modification of signed content)
• Must maintain timestamp accuracy
• Must respect visibility settings
• Must not claim proofs as originating from external system

Cross-Network Compatibility

Proof Portability

Proofs created in Signal Network can be:

• Exported to other trust networks (with attribution)
• Verified by external systems using our verification API
• Embedded in external documents with integrity preserved

External Proof Import

Proofs from external systems can be imported if:

• They conform to Signal HTML Schema v1
• Origin system is declared (no false attribution)
• Timestamps can be independently verified

Imported proofs are marked with origin system and may have reduced SignalRank weight.

Protocol Bridges

Blockchain Anchoring (Optional)

For users requiring additional immutability guarantees:

• Proof hashes can be anchored to public blockchains
• Signal Network does not require blockchain for operation
• Anchoring is user-initiated and user-paid

Identity Federation

Node identity can be linked to:

• Domain ownership (DNS verification)
• Social accounts (OAuth verification)
• Professional credentials (manual verification)

Linked identities increase node credibility but are not required.

Vendor Independence

Signal Network commits to:

• No proprietary formats for core data
• Published specifications for all data structures
• Open source reference implementations where possible
• No artificial barriers to data export

If Signal Network disappears, your proofs remain usable.

Welcome

You're joining a network designed to preserve the value of human judgment in the age of AI. This manual explains how to get started.

Step 1: Create Your Node

1. Visit signalnetwork.ai and select "Create Node"
2. Choose your node identifier (permanent, choose carefully)
3. Verify your identity through one supported method
4. Accept the Constitution and Bill of Rights
5. Complete your profile (optional but recommended)

Step 2: Understand the Basics

What is a Proof?

A proof is a timestamped record of your thinking — a prediction, decision, claim, correction, contribution, or witness attestation. Proofs are your track record.

What is SignalRank?

SignalRank measures your demonstrated judgment over time. It's earned through accurate predictions, sound reasoning, and honest corrections — not followers or engagement.

What is Witnessing?

Witnessing means attesting that someone else's proof existed at a specific time. It's how the network verifies timing without central authority.

Step 3: Create Your First Proof

Start simple:

1. Make a prediction about something in your area of knowledge
2. Set a clear outcome window (when we'll know if you were right)
3. Define verification criteria (how we'll judge the outcome)
4. Submit and optionally request witnesses

Your first proof doesn't need to be profound. It needs to be honest and verifiable.

Step 4: Build Your Network

• Follow nodes whose thinking you want to track
• Request witnesses for important proofs
• Witness others when you can verify their timing
• Engage thoughtfully — quality over quantity

What NOT to Do

• Don't spam proofs: Volume doesn't increase SignalRank
• Don't hedge: Making contradictory predictions is detected and penalized
• Don't delete: Witnessed proofs can't be removed; own your mistakes
• Don't fake: False witnessing is a permanent ban offense

Resources

• Constitution: The foundational principles
• Bill of Rights: Your guaranteed protections
• Proof-of-Mind Doctrine: Why this matters
• Code of Conduct: Community standards

Getting Help

Questions? Issues?

• Community forum: community.signalnetwork.ai
• Documentation: docs.signalnetwork.ai
• Direct support: [email protected]

Your First 30 Days

Goals for new nodes:

• Week 1: Create first proof, read core governance docs
• Week 2: Request or provide your first witness
• Week 3: Follow 5+ nodes in your areas of interest
• Week 4: Review your first proof's progress, make corrections if

Types of Termination

Voluntary Termination

Any node may choose to leave Signal Network at any time, for any reason, without penalty.

Involuntary Termination

Nodes may be terminated by governance action for severe violations. This requires due process.

Voluntary Termination Process

1. Request: Submit termination request through Node Dashboard
2. Confirmation: Confirm you understand the consequences (see below)
3. Cooling off: 7-day waiting period (can be cancelled)
4. Export: Automatic data export generated
5. Execution: Node deactivated after waiting period

What Happens to Your Data

Preserved (Cannot Be Deleted)

• Witnessed proofs: Other nodes have copies; removing yours would break integrity
• ProofLocked content: Immutable by design
• Governance actions: Your votes and decisions remain on record
• Witness attestations you gave: Others relied on your verification

Deleted

• Private proofs (self-visibility only)
• Draft proofs (never witnessed)
• Profile information and preferences
• Connection lists

Anonymized

• Preserved proofs attributed to "terminated-node-[hash]"
• Your readable node ID is no longer publicly associated

Node ID Reservation

After termination:

• Your node ID cannot be claimed by anyone else
• This prevents impersonation of former nodes
• If you return, you must create a new node ID

Involuntary Termination

Grounds

• False witnessing (confirmed)
• Coordinated manipulation (confirmed)
• Severe Code of Conduct violations
• Legal requirement

Process

1. Investigation: Compliance team documents violation
2. Notice: Node informed of charges and evidence
3. Response: Node has 14 days to respond
4. Hearing: Governance review of evidence and response
5. Decision: Termination or lesser sanction
6. Appeal: Node may appeal within 30 days

Immediate Suspension

In cases of ongoing harm, nodes may be suspended immediately pending investigation. Suspension is not termination — rights are restored if cleared.

Returning After Voluntary Termination

• You may create a new node at any time
• Your old proofs remain attributed to terminated node
• You may not claim continuity with old node
• SignalRank starts fresh

Returning After Involuntary Termination

• Permanent terminations cannot be reversed
• Creating new nodes to evade termination is itself a violation
• Time-limited terminations specify return conditions

Purpose

Signal Network is documentary infrastructure. The value of proofs increases over time as predictions resolve and patterns emerge. This policy ensures data survives for the long term.

Retention Periods

Permanent Retention

• All ProofLocked content
• All witnessed proofs
• Governance decisions and votes
• Compliance and audit logs

Extended Retention (10 years minimum)

• All verified proofs
• SignalRank historical calculations
• Node activity logs

Standard Retention (3 years)

• Draft proofs (never published)
• System logs
• Session data

Short Retention (90 days)

• Temporary files
• Cache data
• Failed submission attempts

Archive Format

Archived data is stored in:

• Primary: Signal HTML Schema v1 (human-readable)
• Secondary: JSON (machine-readable)
• Backup: Compressed bundles with integrity checksums

Formats are documented and open — data remains accessible even if Signal Network software changes.

Redundancy

Critical data maintained in:

• Primary storage (active system)
• Hot backup (real-time replication)
• Cold backup (daily snapshots, geographically distributed)
• Witness nodes (distributed copies of witnessed proofs)

No single failure can destroy the archive.

Access to Archives

Public Archives

Public proofs are accessible indefinitely through:

• Web interface
• API
• Bulk export (with rate limits)

Personal Archives

Nodes can access their complete history including:

• All proofs (public, network, private)
• Activity logs
• SignalRank history

Research Access

Academic and research access to anonymized aggregate data available upon request. Individual-level data requires node consent.

Archive Integrity

Checksums

All archived content includes cryptographic checksums. Any modification is detectable.

Audit Trail

Archive access and any administrative operations are logged.

Regular Verification

Monthly integrity checks confirm archive consistency.

Network Shutdown Provisions

If Signal Network ceases operations:

1. 90-day minimum notice to all nodes
2. Full export tools available throughout notice period
3. Complete public archive deposited with multiple institutions
4. Archive format documentation published for future access

Your proofs survive the network.

Principle

Governance evolves. What doesn't change is the requirement for transparency about what changed, when, and why. Version control ensures no change happens in the dark.

What is Versioned

• All governance documents
• Protocol specifications
• API contracts
• Schema definitions
• Terms of service

Version Numbering

Format: MAJOR.MINOR.PATCH

• MAJOR: Breaking changes or fundamental shifts
• MINOR: New features or significant additions
• PATCH: Clarifications, typo fixes, minor adjustments

Examples

• 1.0.0 → 1.0.1: Fixed typo in Section 3
• 1.0.1 → 1.1.0: Added new proof type
• 1.1.0 → 2.0.0: Changed core proof schema (breaking)

Change Process

PATCH Changes

1. Author proposes change
2. Review by one governance member
3. Publish immediately
4. Announce in changelog

MINOR Changes

1. Author proposes change with rationale
2. 7-day comment period
3. Review by governance committee
4. Publish with 14-day notice

MAJOR Changes

1. Author proposes change with full impact analysis
2. 30-day comment period
3. Community vote (if Amendment Procedure requires)
4. Governance approval
5. Publish with 90-day transition period

Changelog Requirements

Every version change must document:

• Version number (old → new)
• Date of change
• Author of change
• Summary of what changed
• Rationale for change
• Link to discussion/approval

Access to History

• All previous versions permanently accessible
• Diff view available (what changed between versions)
• Full changelog searchable
• No version can be deleted or hidden

User-Facing vs Internal

User-Facing Documents

Clean titles without version numbers. Users see "Constitution" not "Constitution v2.3.1". Version information available on demand but not cluttering the interface.

Internal/Technical Documents

Full version numbers in headers for precision. Technical integrators need to know exactly which version they're implementing.

Immutable Content

Some content cannot be versioned because it cannot be changed:

• ProofLocked protocols (immutable after lock)
• Historical proofs (timestamp integrity)
• Audit logs (accountability requirement)

These items have a single permanent version.

Deprecation

When content is replaced rather than updated:

1. Old document marked "Deprecated"
2. Pointer to replacement document
3. Old document remains accessible (historical reference)
4. Deprecation announcement with explanation

Core Philosophy

Traditional platforms incentivize engagement — clicks, likes, shares. These metrics reward noise. Signal Network incentivizes demonstrated judgment — accuracy, consistency, intellectual honesty. Our incentives reward signal.

What We Reward

Accurate Predictions

Predictions that resolve correctly increase SignalRank. The harder the prediction (against consensus, specific criteria, longer time horizon), the greater the reward.

Honest Corrections

Acknowledging errors publicly recovers more SignalRank than quietly abandoning wrong predictions. We reward intellectual honesty.

Quality Witnessing

Witnessing proofs that turn out to be high-quality slightly boosts your SignalRank. Your reputation is connected to those you vouch for.

Consistent Behavior

Long-term coherent participation beats sporadic bursts. Time in network with maintained quality compounds.

Valuable Contributions

Proofs that others reference, build upon, or find useful signal value creation.

What We Penalize

Hedging

Making contradictory predictions to guarantee one is "right" triggers significant SignalRank penalty.

Gaming

Suspicious patterns (timing manipulation, coordinated rings, volume spam) are detected and penalized.

False Witnessing

The most severe violation. Permanent ban and public record.

Noise Generation

Low-quality, high-volume proofs don't increase rank and may decrease it if pattern is detected.

Revenue Model

Signal Network sustains itself through:

Signal Passport Subscriptions

Premium features for serious users:

• Advanced analytics on your proof history
• Priority witness matching
• Extended API access
• Custom domain for node profile

Proof Infrastructure Fees

Enterprise users pay for:

• Bulk proof verification
• Integration support
• SLA guarantees

Enterprise Licensing

Organizations deploy Signal Network internally for:

• Decision documentation
• Prediction tracking
• Accountability infrastructure

What We Don't Do

No Token

We don't have a cryptocurrency or speculative token. SignalRank is reputation, not currency.

No Advertising

We don't sell attention. Your proofs are not surrounded by ads.

No Data Sales

We don't sell user data. Ever.

No Engagement Optimization

We don't optimize for time-on-site or addiction. Quality over quantity.

Node Economics

Free Tier

• Create unlimited public proofs
• Basic SignalRank visibility
• Standard witness access
• Community support

Signal Passport (Paid)

• Everything in Free
• Private proofs
• Advanced analytics
• Priority features
• Direct support

Long-Term Alignment

Signal Network succeeds when nodes succeed in building verifiable track records. Our incentives align:

• Nodes want accurate predictions → Network rewards accuracy
• Nodes want credibility → Network measures real judgment
• Nodes want persistence → Network preserves records
• Network wants quality → Nodes are incentivized for quality

Partnership Philosophy

Signal Network partners with organizations that share our commitment to trust, transparency, and verified behavior. We don't partner for reach or revenue alone — alignment matters.

Partner Categories

Integration Partners

Organizations that build on Signal Network infrastructure:

• Apps using our API
• Platforms embedding proof verification
• Tools that generate Signal-compatible proofs

Distribution Partners

Organizations that bring Signal Network to their users:

• Media companies
• Professional networks
• Educational institutions

Verification Partners

Organizations that help verify real-world outcomes:

• Data providers
• News organizations
• Research institutions

Strategic Partners

Organizations aligned on mission:

• Trust and safety initiatives
• AI accountability projects
• Open data movements

Partnership Requirements

Must Have

• Alignment with Signal Network values (see Constitution)
• Clear mutual benefit
• Technical capability to integrate properly
• Commitment to user privacy

Must Not Have

• History of data misuse or privacy violations
• Business model based on misinformation
• Engagement optimization that rewards noise
• Practices that would compromise proof integrity

Evaluation Process

1. Initial Review: Basic alignment check against requirements
2. Due Diligence: Technical and values assessment
3. Terms Negotiation: Define scope, responsibilities, limits
4. Governance Review: Atlas Node approval for significant partnerships
5. Public Disclosure: All partnerships announced (no secret deals)
6. Ongoing Review: Annual reassessment of partnership health

Partnership Boundaries

What Partners Can Do

• Access public API
• Display Signal Network data with attribution
• Integrate proof submission for their users
• Co-market with Signal Network

What Partners Cannot Do

• Modify proof data
• Access private user information
• Claim exclusive rights to Signal Network features
• Represent themselves as Signal Network
• Override governance decisions

Revenue Sharing

Where partnerships generate revenue:

• Integration partners: API tier pricing, possible revenue share on premium features
• Distribution partners: Referral fees for converted users
• Enterprise partners: Custom licensing terms

All revenue terms documented and disclosed in partnership announcements.

Partnership Termination

Partnerships end when:

• Either party gives 90-day notice
• Partner violates partnership requirements
• Partner's practices become misaligned with values
• Mutual agreement to conclude

Termination process includes user notification and data transition support.

Transparency

All active partnerships listed publicly at signalnetwork.ai/partners with:

• Partner name and description
• Partnership type and scope
• Start date
• Any revenue relationship (yes/no, not specific terms)

Sustainability Principles

Signal Network is built to outlast its founders. These principles ensure long-term viability:

• Revenue before growth: We prioritize sustainable economics over rapid scaling
• Quality over quantity: 1,000 high-signal nodes matter more than 1,000,000 noise generators
• Independence: No single funder, partner, or user can compromise the network
• Succession: Systems and governance designed to function without any individual

Financial Sustainability

Revenue Targets

• Year 1: Establish revenue streams, accept operating loss
• Year 2: Cover operating costs
• Year 3-4: Break even
• Year 5+: Sustainable surplus for development and reserves

Reserve Policy

Maintain minimum 12 months operating expenses in reserve. This ensures continuity through market disruptions.

Funding Independence

No single source (investor, partner, customer) represents more than 25% of revenue. Diversification prevents capture.

Growth Strategy

Phase 1: Foundation (Current)

• Core infrastructure operational
• Governance framework complete
• Initial nodes onboarded
• Proof-of-concept demonstrated

Phase 2: Validation

• First 100 active nodes
• First prediction cycles complete (outcomes verified)
• SignalRank producing meaningful differentiation
• First paying customers

Phase 3: Expansion

• 1,000+ active nodes
• Multiple domain verticals active
• Integration partners live
• Revenue covering operations

Phase 4: Maturity

• Self-sustaining node growth
• Established reputation in target markets
• Governance fully decentralized from founders
• Long-term financial sustainability proven

Growth Constraints

We intentionally limit growth when:

• Quality would suffer: If onboarding speed exceeds capacity to maintain standards
• Infrastructure strains: If technical systems can't support user experience
• Governance lags: If decision-making can't keep pace with issues
• Culture dilutes: If network norms aren't being transmitted to new nodes

Sustainable growth > fast growth.

Succession Planning

Founder Transition

Signal Network must function without its founders. Plan includes:

• Document all critical knowledge and decisions
• Distribute authority to Atlas Nodes over time
• Establish clear succession for all key roles
• Test governance function without founder participation

Key Person Risk

No individual should be irreplaceable. Mitigations:

• Cross-training on all critical functions
• Documented procedures for all operations
• Distributed access to critical systems

Existential Risk Mitigation

Technical Failure

Multiple backups, documented recovery procedures, regular disaster drills.

Legal Challenge

Legal structure reviewed, insurance maintained, jurisdiction diversification considered.

Market Irrelevance

Continuous assessment of product-market fit, willingness to evolve while maintaining core principles.

Capture

Governance designed to resist capture by any faction — investors, large users, or internal parties.

Measuring Success

Signal Network succeeds when:

• Nodes build verifiable track records that matter outside the network
• SignalRank becomes a trusted indicator of demonstrated judgment
• The network operates sustainably without depending on any individual
• Proofs created today remain accessible and verifiable decades from now

Protocol Status Legend

• LOCKED — ProofLocked — Immutable, cannot be changed
• ACTIVE — Active — In production, stable
• DRAFT — Draft — Documented, subject to change
• REF — Reference — Informational only

A. Memory & Identity Protocols

B. Behavioral Protocols

C. Governance Protocols

D. Time Protocols

E. Scientific & Audit Protocols

F. Communication Protocols

G. Verification & Proof Protocols

H. Defense & Security Protocols

I. Infrastructure Protocols

ProofLock Candidates

The following protocols are candidates for ProofLock after network launch and validation:

1. Signal HTML Schema v1
2. SignalRank Core Formula
3. Node Identity Protocol
4. Timestamp Integrity Protocol
5. Bill of Rights
6. Constitution Core Principles
7. Witness Verification Protocol
8. Data Protection Protocol
9. ProofChain Protocol
10. Outcome Resolution Protocol

These will be locked post-traction, not pre-launch.

The Proof

This is the verbatim, immutable text of the Scarcity Thesis as ProofLocked on February 5, 2026. No modification is permitted. Interpretation, extension, or challenge must occur in separate proofs that reference this one.

"As AI commoditizes content generation, verified reasoning processes become the scarce resource — not because reasoning is rare, but because demand for attributable, auditable reasoning rises as institutional trust in unverified outputs collapses. AI can generate reasoning, but cannot independently verify its own provenance. Multiple verification approaches exist — cryptographic proofs, multi-agent consensus, zero-knowledge attestation — but these verify logical correctness, not intent. Proof-of-Mind is distinct because it documents not just who reasoned and when, but under what constraints and with what stake. Correctness can be automated because it is internally verifiable; accountability resists automation because it requires validation from outside the system that produced the reasoning — attribution, stake, and consequence cannot be self-certified without collapsing trust. This is the resource that resists commoditization."

Structural Analysis

The proof contains four load-bearing claims, each independently falsifiable:

Witness History

Five witness runs across three revisions. Each run exposed structural gaps that were addressed in the subsequent revision. The protocol used was Witness Protocol v1.1.

Gaps Closed Through Revision

• Closed Demand-side anchor: who values verified reasoning and why?
• Closed Reflexivity defense: can AI verify its own provenance?
• Closed Alternative methods acknowledged: cryptographic proofs, ZK, consensus.
• Closed Internal/external distinction: why accountability resists automation.

Deferred to Future Proofs

The following items were identified during witness runs as legitimate open questions. They are out of scope for a thesis-level proof and are deferred to implementation-layer documents. They do not retroactively affect the validity of this thesis.

• Deferred Proof-of-Mind implementation specification: what data, how stored, privacy model.
• Deferred "Stake" operationalization: what constitutes stake in the system.
• Deferred Empirical grounding of trust-collapse premise.
• Deferred Gaming and adversarial resistance model.

ProofLock Rationale

This proof was locked after five witness runs because all four ProofLock criteria defined in GOV-WP-1.1 Section 6 were satisfied:

Significance

This is the first thesis-level proof locked using the live Witness Protocol. The protocol itself was built and validated through the process of producing this proof — making this simultaneously the first test case and the first canonical output of Signal Network's three-model witness infrastructure.

The Scarcity Thesis is foundational. All subsequent Signal Network architecture — Proof-of-Mind specifications, SignalRank formulas, node governance, and product design — derives from the claim documented here. If this thesis is falsified, the system's value proposition must be re-evaluated from first principles.

Amendment Log

Purpose

This document is the canonical registry of all Signal Network development sessions. It exists because the project's own thesis demands it: process is the scarce resource, not output. If the reasoning that built Signal Network cannot be traced, the system fails its own standard.

Each session is a unit of work with identifiable inputs, outputs, and decisions. Sessions may span multiple hours and multiple chats. Sub-sessions (e.g., 5.1, 5.2, 5.3) indicate continuous work within a single build arc that was interrupted by tool changes, not by intent.

Summary

Session Log

Phase Definitions

Phase 1 — Architecture and Doctrine. Concept validation, financial modeling, canonical document creation, schema design, and terminology standardization. No deployed infrastructure. Output: the intellectual foundation.

Phase 2 — Infrastructure Build. Server deployment, API creation, WordPress node, governance site, MCP middleware, proof submission and storage. Output: working systems on production servers.

Phase 3 — Witness Infrastructure. Cross-model validation pipeline, three-model witness protocol, live ProofLock process, governance documentation of operational procedures. Output: the trust layer is operational.

Numbering Convention

Sessions are numbered sequentially starting from 0. Sub-sessions (e.g., 5.1, 5.2, 5.3) indicate a continuous build arc where the operator maintained intent continuity across multiple chats due to tool limitations, context window resets, or platform changes. Sub-sessions share a parent number because they share a parent goal.

Session 0 is the viability assessment — the moment the project moved from idea to structured evaluation. Sessions before this (informal thinking, notes, research) are not tracked here.

Future sessions continue from the last integer. The next session after this document is Session 11.

Cross-Model Context

Signal Network development has occurred across multiple AI systems. Sessions 0–3 were primarily conducted with Claude (Anthropic) and GPT (OpenAI) independently, with the operator manually routing context between models. Session 4 introduced the MCP comparison tool, enabling direct cross-model calls. Session 9 completed the full pipeline with four registered tools.

GPT maintained a separate session count that diverged from Claude's count due to different chat boundaries. This registry reconciles both counts into a single canonical sequence. Where GPT and Claude disagree on session boundaries, the operator's stated session number at the time of the chat is authoritative.

Infrastructure State (as of Session 10)

Amendment Log