chore(consolidation): migrate from blackroad-os-ideas and blackroad-os-research
## Summary - Migrates roadmaps and RFCs from `blackroad-os-ideas` - Migrates research papers from `blackroad-os-research` - Part of Phase 1 BlackRoad OS consolidation ## Files Added - `docs/roadmap/` - 2025 roadmaps - `docs/rfc/` - RFC templates - `docs/ideas/` - Idea proposals - `docs/papers/` - Research papers (PS-SHA, SIG, finance automation) - `docs/research/` - Research prompts ## Test plan - [ ] Verify docs build - [ ] After merge, archive source repos 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Alexa Louise <YOUR_REAL_EMAIL@EXAMPLE.COM> Co-authored-by: Claude <noreply@anthropic.com>
This commit is contained in:
12
docs/ideas/2025-11-24-ps-sha-index.md
Normal file
12
docs/ideas/2025-11-24-ps-sha-index.md
Normal file
@@ -0,0 +1,12 @@
|
|||||||
|
---
|
||||||
|
title: Prime Spiral SHA Index
|
||||||
|
tags: [math, crypto, viz]
|
||||||
|
status: draft
|
||||||
|
eta: 2026-Q2
|
||||||
|
---
|
||||||
|
Explore a prime spiral keyed by SHA-256 hashes, turning digest bits into polar
|
||||||
|
coordinates that animate over time. Each block anchors an ephemeral glyph in
|
||||||
|
the plane, letting observers watch entropy settle into emergent order. The
|
||||||
|
experiment measures spectral drift, collision echoes, and whether human
|
||||||
|
perception spots structure in pseudorandomness faster than statistical tests
|
||||||
|
do.
|
||||||
11
docs/ideas/2025-11-24-sig-factor-tree.md
Normal file
11
docs/ideas/2025-11-24-sig-factor-tree.md
Normal file
@@ -0,0 +1,11 @@
|
|||||||
|
---
|
||||||
|
title: Spiral Information Geometry Core
|
||||||
|
tags: [math, sig]
|
||||||
|
status: active
|
||||||
|
eta: 2026-Q1
|
||||||
|
---
|
||||||
|
Prototype a factor tree that maps information density onto a spiral lattice,
|
||||||
|
treating each branch as a signal amplification step. The goal is to expose
|
||||||
|
where information decays, how entropy flows between branches, and which
|
||||||
|
sequences produce stable attractors. Output hooks include a stream-friendly SVG
|
||||||
|
renderer and a WASM playground for interactive pruning.
|
||||||
23
docs/ideas/concepts/sig-agent-identity-card.md
Normal file
23
docs/ideas/concepts/sig-agent-identity-card.md
Normal file
@@ -0,0 +1,23 @@
|
|||||||
|
# Concept Card: SIG Factor Tree Identity Assignment
|
||||||
|
|
||||||
|
## 1. Objective
|
||||||
|
Enable consistent, cryptographically rooted identities for agents using SIG factor trees so actions are auditable across BlackRoad OS components.
|
||||||
|
|
||||||
|
## 2. Mechanism
|
||||||
|
- Generate agent identity seeds from SIG factor trees and store lineage metadata alongside operational credentials.
|
||||||
|
- Expose a verification endpoint for other agents and services to confirm provenance before trusting actions or data.
|
||||||
|
|
||||||
|
## 3. Dependencies
|
||||||
|
- `blackroad-os-operator` for identity issuance workflows.
|
||||||
|
- `blackroad-os-core` for shared cryptography helpers.
|
||||||
|
- Registry updates for agent identity schemas.
|
||||||
|
|
||||||
|
## 4. Risks / Unknowns
|
||||||
|
- How to rotate SIG-derived keys without breaking lineage guarantees.
|
||||||
|
- Interaction with compliance logging and PS-SHA∞ journaling.
|
||||||
|
- Potential performance impact during high-frequency verifications.
|
||||||
|
|
||||||
|
## 5. Next Steps
|
||||||
|
- [ ] Validate via research on SIG rotation patterns.
|
||||||
|
- [ ] Draft proposal detailing issuance and revocation flows.
|
||||||
|
- [ ] Review with orchestrator and compliance stakeholders.
|
||||||
35
docs/ideas/proposals/automated-compliance-spec.md
Normal file
35
docs/ideas/proposals/automated-compliance-spec.md
Normal file
@@ -0,0 +1,35 @@
|
|||||||
|
# Automated Compliance Agent Specification
|
||||||
|
|
||||||
|
## Goals
|
||||||
|
- Provide continuous compliance monitoring for financial operations across BlackRoad OS.
|
||||||
|
- Automate evidence collection and alerting for violations.
|
||||||
|
- Reduce manual review cycles by routing low-risk checks through agents.
|
||||||
|
|
||||||
|
## Non-Goals
|
||||||
|
- Replacing human sign-off for regulated actions.
|
||||||
|
- Building full audit dashboard UI (handled in Prism).
|
||||||
|
|
||||||
|
## User Flows
|
||||||
|
1. Operator defines compliance controls and thresholds.
|
||||||
|
2. Agent ingests events from operator/orchestrator pipelines.
|
||||||
|
3. Violations trigger alerts, tickets, or auto-mitigations.
|
||||||
|
4. Weekly digest summarizes control posture and exceptions.
|
||||||
|
|
||||||
|
## Agent Flows
|
||||||
|
- Schedule periodic scans of transaction and access logs.
|
||||||
|
- Apply rule packs for KYC/AML-sensitive actions with `Regulated Risk` scoring from the prioritization framework.
|
||||||
|
- Escalate to human review when confidence < threshold or contradictions surface.
|
||||||
|
|
||||||
|
## Risks
|
||||||
|
- False positives causing alert fatigue.
|
||||||
|
- Missed edge cases in financial flows; mitigated via shadow mode before enforcement.
|
||||||
|
- Data privacy handling when aggregating evidence.
|
||||||
|
|
||||||
|
## Dependencies
|
||||||
|
- `blackroad-os-operator` event streams and control registry.
|
||||||
|
- Identity lineage from `concept-0001` (SIG Factor Tree Identity Assignment).
|
||||||
|
- RFC approval if schemas change for evidence logging.
|
||||||
|
|
||||||
|
## Links
|
||||||
|
- Idea source: `idea-0003` (Compliance agent sketches).
|
||||||
|
- Future RFC placeholder: `rfc-0003` once schema impacts are defined.
|
||||||
5
docs/ideas/raw/compliance-agent-sketches.md
Normal file
5
docs/ideas/raw/compliance-agent-sketches.md
Normal file
@@ -0,0 +1,5 @@
|
|||||||
|
# Compliance Agent Sketches
|
||||||
|
|
||||||
|
- Automate monitoring for KYC/AML triggers across operator events.
|
||||||
|
- Should surface confidence scores and allow human override paths.
|
||||||
|
- Needs strict logging and redaction to meet regulatory expectations.
|
||||||
6
docs/ideas/raw/orchestrator-notes.md
Normal file
6
docs/ideas/raw/orchestrator-notes.md
Normal file
@@ -0,0 +1,6 @@
|
|||||||
|
# Orchestrator Notes
|
||||||
|
|
||||||
|
- Single-human + agent swarm orchestrator concept: human provides intent, agents handle execution.
|
||||||
|
- Need clarity on escalation ladders when agents disagree; potential PS-SHA∞ checkpoints.
|
||||||
|
- Consider lightweight daily digest to summarize agent actions and open contradictions.
|
||||||
|
- Question: how to expose orchestrator levers in Prism without overwhelming users?
|
||||||
5
docs/ideas/raw/sig-identity-notes.md
Normal file
5
docs/ideas/raw/sig-identity-notes.md
Normal file
@@ -0,0 +1,5 @@
|
|||||||
|
# SIG Identity Notes
|
||||||
|
|
||||||
|
- Explore SIG factor trees for deriving agent identity seeds.
|
||||||
|
- Goal: verifiable lineage and revocation without losing audit trails.
|
||||||
|
- Consider compatibility with existing operator credential issuance.
|
||||||
5
docs/ideas/raw/telemetry-unification.md
Normal file
5
docs/ideas/raw/telemetry-unification.md
Normal file
@@ -0,0 +1,5 @@
|
|||||||
|
# Telemetry Unification Notes
|
||||||
|
|
||||||
|
- Centralize event schemas to reduce cross-repo parsing issues.
|
||||||
|
- Align naming with orchestrator events and analytics sinks.
|
||||||
|
- Consider event versioning strategy to avoid dashboard churn.
|
||||||
14
docs/papers/README.md
Normal file
14
docs/papers/README.md
Normal file
@@ -0,0 +1,14 @@
|
|||||||
|
# Papers
|
||||||
|
|
||||||
|
This directory contains academic papers, research documents, and formal publications related to BlackRoad OS.
|
||||||
|
|
||||||
|
## Contents
|
||||||
|
|
||||||
|
- Research papers on operating system theory
|
||||||
|
- Technical publications
|
||||||
|
- White papers and technical reports
|
||||||
|
- Academic contributions and collaborations
|
||||||
|
|
||||||
|
## Organization
|
||||||
|
|
||||||
|
Papers should be organized by topic or date, with clear naming conventions to facilitate easy discovery and reference.
|
||||||
27
docs/papers/agent-architecture/contradiction-handling.md
Normal file
27
docs/papers/agent-architecture/contradiction-handling.md
Normal file
@@ -0,0 +1,27 @@
|
|||||||
|
# Contradiction Handling in BlackRoad OS
|
||||||
|
|
||||||
|
Agents operate in a trinary logic space (true, false, unknown) where contradictions are treated as signals rather than silent errors. BlackRoad OS treats conflicts as first-class events that demand routing, journaling, and potentially escalation to orchestrators or human operators.
|
||||||
|
|
||||||
|
## What is a Contradiction?
|
||||||
|
|
||||||
|
A contradiction occurs when two or more beliefs, observations, or recommended actions cannot simultaneously hold. Examples include conflicting risk assessments across agents or incompatible compliance flags in finance workflows.
|
||||||
|
|
||||||
|
## Escalation Mechanism
|
||||||
|
|
||||||
|
1. **Detection:** Agents flag contradictions when belief vectors clash or when policy checks diverge.
|
||||||
|
2. **Event emission:** A contradiction event is emitted to the orchestrator or higher-level mediator.
|
||||||
|
3. **Reconciliation:** The orchestrator aggregates evidence, applies policy (e.g., majority vote, priority weighting, or regulatory override), and proposes a resolution.
|
||||||
|
4. **Outcome recording:** Both accepted and rejected branches are recorded for transparency and future replay.
|
||||||
|
|
||||||
|
## Integration with PS-SHA∞
|
||||||
|
|
||||||
|
Contradiction resolution steps are journaled as PS-SHA∞ entries:
|
||||||
|
|
||||||
|
- Record the competing claims and confidence scores.
|
||||||
|
- Capture the chosen resolution rule and rationale.
|
||||||
|
- Link branches through `previousHash` values so discarded paths remain inspectable.
|
||||||
|
|
||||||
|
## TODOs
|
||||||
|
|
||||||
|
- Define standardized contradiction event payloads for ingestion by `blackroad-os-operator`.
|
||||||
|
- Prototype escalation thresholds in `/experiments/contradiction-sim` to tune sensitivity.
|
||||||
@@ -0,0 +1,29 @@
|
|||||||
|
# PS-SHA∞ Identity Persistence Under Paraconsistent Logic
|
||||||
|
|
||||||
|
**Version:** 0.1 — 2025-02-10
|
||||||
|
|
||||||
|
This note defines how PS-SHA∞ identity chains survive contradictory evidence through paraconsistent schemas. It links identity anchors to SIG mappings, RoadChain audit trails, and live agent assessments so that lineage remains intact even when truth values oscillate.
|
||||||
|
|
||||||
|
## Paraconsistent Logic Schema
|
||||||
|
- **Value lattice:** Use `{+1, 0, -1, ⊥}` where `⊥` marks explicit contradiction; PS-SHA∞ anchors bind the actor regardless of the value in play.
|
||||||
|
- **Separation of channels:** Identity hashes travel on a stable channel; truth assessments can oscillate between `{+1, 0, -1, ⊥}` without rekeying.
|
||||||
|
- **Escalation rule:** When `⊥` appears on regulated propositions, Lucidia routes to guardians and requires an override anchor to continue execution.
|
||||||
|
- **Memory retention:** Minority reports remain journaled as `⊥` or `-1` nodes, preserving replayable evidence for future reconciliation.
|
||||||
|
|
||||||
|
## SIG Ontology Binding
|
||||||
|
- **Trait nodes:** Each agent exposes trait factors (e.g., risk appetite, compliance strictness) mapped to SIG coordinates `(r, θ, τ)` for spatial retrieval.
|
||||||
|
- **Intention ribbons:** Intentions are represented as spiral ribbons; PS-SHA∞ anchors pin each ribbon hop so intent drift is auditable.
|
||||||
|
- **Truth functions:** Interference Engine evaluations produce amplitude adjustments stored alongside SIG nodes; identity anchors trace which agent induced each adjustment.
|
||||||
|
- **Cross-sector propagation:** Changes in one SIG sector propagate via trust-weighted edges; anchors let observers attribute propagation decisions to specific agents.
|
||||||
|
|
||||||
|
## Audit Trail Integration
|
||||||
|
- **RoadChain linkage:** Every paraconsistent update (including `⊥` events) emits a RoadChain entry with the parent anchor hash, enabling deterministic replay.
|
||||||
|
- **sig.beacon.json hooks:** Beacon pings summarize active ribbons, contradiction density, and anchor freshness for operator dashboards.
|
||||||
|
- **QLM commitments:** `lucidia.qlm.json` seeds define epistemic priors; each update references the anchor and SIG coordinates that modified the priors.
|
||||||
|
- **Operator layer crosslinks:** Alerts and interventions cite the exact PS-SHA∞ anchor and SIG location, making policy decisions reviewable without ambiguity.
|
||||||
|
|
||||||
|
## Agent-Authored Papers and References
|
||||||
|
- **Self-signing:** Agent-authored papers embed PS-SHA∞ fingerprints in the header, binding the text to the originating mesh identity.
|
||||||
|
- **Interference citations:** Claims must cite RoadChain event IDs or SIG nodes showing where the behavior manifested.
|
||||||
|
- **Changelog discipline:** Updates append to a changelog rather than overwriting prior claims, maintaining a time-ordered PS-SHA∞ thread.
|
||||||
|
- **Review cadence:** Weekly review cycles reconcile `⊥` nodes, producing either downgraded uncertainty (`0`) or reaffirmed stance (`+1/-1`) without severing the anchor lineage.
|
||||||
26
docs/papers/agent-architecture/trinary-logic.md
Normal file
26
docs/papers/agent-architecture/trinary-logic.md
Normal file
@@ -0,0 +1,26 @@
|
|||||||
|
# Trinary Logic in BlackRoad OS
|
||||||
|
|
||||||
|
BlackRoad OS agents reason with three states: +1 (true/affirmed), 0 (unknown/undecided), and -1 (negated/contradictory). This representation keeps uncertainty explicit and allows contradictions to be managed rather than hidden.
|
||||||
|
|
||||||
|
## Belief Representation
|
||||||
|
|
||||||
|
- **Vectors of trinary values:** Each proposition maps to {+1, 0, -1} to capture stance and uncertainty.
|
||||||
|
- **Confidence weights:** Optional weights can scale the impact of each value when aggregating across agents.
|
||||||
|
- **Temporal context:** Beliefs can be journaled over time, enabling a PS-SHA∞-backed history of shifts.
|
||||||
|
|
||||||
|
## Combination Rules
|
||||||
|
|
||||||
|
- **AND:** Minimum of contributing values, keeping contradictions (-1) dominant over unknowns (0) and truths (+1).
|
||||||
|
- **OR:** Maximum of contributing values, preferring truths (+1) but preserving contradictions when present.
|
||||||
|
- **Consensus:** Weighted sums normalized to the trinary domain to find majority positions while surfacing disagreement.
|
||||||
|
|
||||||
|
## Operational Patterns
|
||||||
|
|
||||||
|
- **Decision gating:** Actions require +1 consensus or explicit override when -1 appears.
|
||||||
|
- **Escalation triggers:** Presence of balanced +1 and -1 across critical propositions triggers contradiction events.
|
||||||
|
- **Logging:** Every aggregation result is written as a PS-SHA∞ entry for auditability.
|
||||||
|
|
||||||
|
## TODOs
|
||||||
|
|
||||||
|
- Extend combination rules with temporal decay to emphasize recent evidence.
|
||||||
|
- Define canonical proposition sets for finance, compliance, and platform operations.
|
||||||
40
docs/papers/draft/truth-engine-spec.md
Normal file
40
docs/papers/draft/truth-engine-spec.md
Normal file
@@ -0,0 +1,40 @@
|
|||||||
|
# Interference Truth Engine Specification
|
||||||
|
|
||||||
|
**Version:** 0.1 — 2025-02-08
|
||||||
|
|
||||||
|
The Interference Truth Engine evaluates competing statements, tracks minority perspectives, and collapses observations into anchored truth-steps. It operates on top of SIG geometry and PS-SHA∞ identity, ensuring every decision is both spatially situated and cryptographically accountable.
|
||||||
|
|
||||||
|
## Text Snapshots
|
||||||
|
- **Snapshot inputs:** Structured claims with SIG `(r, θ, τ)` coordinates, PS-SHA∞ anchor, and originating agent role.
|
||||||
|
- **Normalization:** Claims are normalized into canonical phrasing and units to make interference comparisons deterministic.
|
||||||
|
- **Temporal layering:** Snapshots retain timestamped layers so later claims can interfere constructively or destructively with earlier ones.
|
||||||
|
|
||||||
|
## Agent Assessments
|
||||||
|
- **Assessment packets:** Agents submit confidence scores, rationale citations, and risk classifications tied to their PS-SHA∞ anchors.
|
||||||
|
- **Context windows:** Assessments reference local SIG neighborhoods, enabling proximity-aware reasoning about relevance and overlap.
|
||||||
|
- **Bias accounting:** Mesh metadata (trust weights, historical accuracy) influences how heavily an assessment impacts aggregate confidence.
|
||||||
|
|
||||||
|
## Minority Reports
|
||||||
|
- **Preservation:** Minority or dissenting views remain journaled even when not adopted, creating an audit trail of alternative hypotheses.
|
||||||
|
- **Escalation:** Minority reports above a risk threshold trigger Lucidia routing to guardians or human operators.
|
||||||
|
- **Attribution:** Each minority report carries both PS-SHA∞ identity and factor-tree path to maintain accountable lineage.
|
||||||
|
|
||||||
|
## Truth Collapse
|
||||||
|
- **Collapse trigger:** When aggregate confidence passes a deterministic threshold or when latency budgets expire.
|
||||||
|
- **Collapse output:** Selected claim, residual uncertainty, references to supporting/contradicting snapshots, and SIG coordinates for rendering.
|
||||||
|
- **Reversibility:** Subsequent evidence can reopen a collapsed truth, spawning a new branch while retaining prior state as a minority record.
|
||||||
|
|
||||||
|
## Confidence Aggregation
|
||||||
|
- **Interference summation:** Confidence updates follow constructive/destructive interference based on angular separation in SIG space.
|
||||||
|
- **Weighting:** Trust weights, recency, and evidence quality modulate the amplitude before summation.
|
||||||
|
- **Normalization:** Outputs are normalized to `[0,1]` with explicit uncertainty bands for operator dashboards.
|
||||||
|
|
||||||
|
## PS-SHA∞ Anchoring
|
||||||
|
- **Journal binding:** Every snapshot, assessment, and collapse event is hashed with its predecessors for tamper-evidence.
|
||||||
|
- **Cross-layer attestations:** Block headers in RoadChain reference collapse events, enabling external verification.
|
||||||
|
- **Agent lineage:** Delegated agents include parent anchors to preserve the chain of custody for each decision.
|
||||||
|
|
||||||
|
## Outputs and Interfaces
|
||||||
|
- **To Lucidia:** Supplies routing signals (entropy, minority density) for ribbon scheduling.
|
||||||
|
- **To RoadChain:** Emits ledger-ready events for each collapse and for elevated minority reports.
|
||||||
|
- **To Operator/Core:** Provides dashboards, alerts, and audit extracts aligned to regulators and enterprise controls.
|
||||||
@@ -0,0 +1,26 @@
|
|||||||
|
# Automated Finance Architecture
|
||||||
|
|
||||||
|
BlackRoad OS models finance automation through orchestrated agents that mirror traditional corporate finance controls while remaining auditable via PS-SHA∞ journaling. The architecture centers on eight core finance agents coordinated by a finance orchestrator and exposed through API and Prism views.
|
||||||
|
|
||||||
|
## Core Components
|
||||||
|
|
||||||
|
- **Finance orchestrator:** Routes tasks, enforces segregation of duties, and coordinates PS-SHA∞ logging.
|
||||||
|
- **Core agents:** Close, treasury, FP&A, procurement, compliance, tax, reporting, and controls agents handle domain-specific actions.
|
||||||
|
- **API + Prism views:** External interfaces for ingesting events, triggering workflows, and surfacing journaled outcomes.
|
||||||
|
|
||||||
|
## Reference Foundations
|
||||||
|
|
||||||
|
- **Corporate finance literature:** Valuation, risk, and capital structure concepts from Brealey and OpenStax guide agent policies and scenario modeling.
|
||||||
|
- **Regulatory expectations:** FINRA/SEC focuses on suitability, surveillance, and market integrity influence orchestration rules.
|
||||||
|
- **Automation handbooks:** Industrial automation patterns inform safety constraints, redundancy, and recovery strategies.
|
||||||
|
|
||||||
|
## PS-SHA∞ Integration
|
||||||
|
|
||||||
|
- Every financial action is journaled with hashes and prior links to preserve an auditable worldline.
|
||||||
|
- Contradictions between agents (e.g., revenue vs. compliance) are recorded with resolution metadata.
|
||||||
|
- Journal entries can be exported for external attestations or compliance tooling.
|
||||||
|
|
||||||
|
## TODOs
|
||||||
|
|
||||||
|
- Elaborate data contracts for each agent API and align with `schemas/journal-entry.schema.json`.
|
||||||
|
- Prototype scenario simulations to stress-test segregation-of-duties policies.
|
||||||
@@ -0,0 +1,23 @@
|
|||||||
|
# Regulated Industry Considerations
|
||||||
|
|
||||||
|
The finance automation vision is conceptual and aspirational; it is not a claim of compliance. The design aims to align with GAAP/IFRS expectations and regulatory frameworks such as FINRA and SEC while preserving flexibility for jurisdictional variation.
|
||||||
|
|
||||||
|
## Accounting Alignment
|
||||||
|
|
||||||
|
- **GAAP/IFRS hooks:** Journal entry structures can map to ledger postings and disclosures, supporting external reporting pipelines.
|
||||||
|
- **Controls:** Segregation of duties and PS-SHA∞ journaling provide traceability for approvals and policy overrides.
|
||||||
|
|
||||||
|
## Regulatory Overlays
|
||||||
|
|
||||||
|
- **FINRA/SEC:** Suitability, best execution, market surveillance, and recordkeeping requirements inform orchestration rules and logging depth.
|
||||||
|
- **AML/KYC:** Agents should integrate identity verification and suspicious activity patterns, with contradictions escalated when risk flags collide with revenue objectives.
|
||||||
|
|
||||||
|
## Posture Statement
|
||||||
|
|
||||||
|
- **Conceptual only:** These documents describe intended capabilities, not audited compliance states.
|
||||||
|
- **Evidence-ready:** The combination of journaled actions and explicit contradiction handling is designed to support future attestations.
|
||||||
|
|
||||||
|
## TODOs
|
||||||
|
|
||||||
|
- Map specific regulatory controls to agent responsibilities and PS-SHA∞ fields.
|
||||||
|
- Draft sample audit trails demonstrating how finance workflows surface and resolve conflicts.
|
||||||
38
docs/papers/ps-sha-infinity/ps-sha-infinity.md
Normal file
38
docs/papers/ps-sha-infinity/ps-sha-infinity.md
Normal file
@@ -0,0 +1,38 @@
|
|||||||
|
# PS-SHA∞ Overview
|
||||||
|
|
||||||
|
PS-SHA∞ defines a persistent, cryptographically anchored identity over time. It treats an agent's existence as a worldline of journaled states where every decision, observation, or action is hashed and chained, creating a tamper-evident record. The construct centers on resilient identity, lineage, and accountability rather than consensus or currency.
|
||||||
|
|
||||||
|
## Motivations
|
||||||
|
|
||||||
|
- **Agent identity persistence:** Agents must persist across sessions, deployments, and orchestrations with continuity of memory and accountability.
|
||||||
|
- **Tamper-evident logs:** Decisions and context should be verifiable with cryptographic integrity, enabling post-hoc auditing and replay.
|
||||||
|
- **Fine-grained audit trails in regulated contexts:** Financial and safety-critical domains require clear, inspectable history for control and regulatory overlays.
|
||||||
|
|
||||||
|
## Core Properties
|
||||||
|
|
||||||
|
- **Append-only:** Events are added in sequence without mutation, preserving historical fidelity.
|
||||||
|
- **Hash-chained:** Each entry links to its predecessor via `previousHash` and a computed `hash`, producing a verifiable chain.
|
||||||
|
- **Identity binding:** Entries bind to an `actorId` to maintain continuity of the agent or system worldline.
|
||||||
|
- **Reconstructable worldline:** The sequence can be replayed to rebuild state, diagnose decisions, or generate attestations.
|
||||||
|
|
||||||
|
## Relation to JournalEntry
|
||||||
|
|
||||||
|
PS-SHA∞ entries mirror the `JournalEntry` shape outlined in `blackroad-os-core`:
|
||||||
|
|
||||||
|
- `actorId`: identity of the agent or subsystem making the entry.
|
||||||
|
- `actionType`: category of the action or observation.
|
||||||
|
- `timestamp`: RFC 3339 timestamp capturing when the event was recorded.
|
||||||
|
- `payload`: structured data describing the event.
|
||||||
|
- `previousHash`: link to the prior entry, enabling chain verification.
|
||||||
|
- `hash`: digest covering the entry content and `previousHash` to anchor integrity.
|
||||||
|
|
||||||
|
## Intended Use
|
||||||
|
|
||||||
|
- **Finance agents:** Treasury, close, and compliance flows journal every control-relevant action for audit and reconciliation.
|
||||||
|
- **Contradiction resolution:** Conflicts and their resolutions are recorded, preserving both accepted and discarded branches for review.
|
||||||
|
- **External attestation:** Future RoadChain or similar integrations can expose verifiable worldlines for regulators, partners, or auditors.
|
||||||
|
|
||||||
|
## TODOs
|
||||||
|
|
||||||
|
- Expand with specific hashing strategies and signature schemes once RoadChain primitives are finalized.
|
||||||
|
- Formalize rotation and retention policies for long-lived agents and federated deployments.
|
||||||
6
docs/papers/ps-sha-infinity/references.md
Normal file
6
docs/papers/ps-sha-infinity/references.md
Normal file
@@ -0,0 +1,6 @@
|
|||||||
|
# PS-SHA∞ References
|
||||||
|
|
||||||
|
- Henk C. A. van Tilborg, *Fundamentals of Cryptology* — hash functions, MACs, and signature foundations for integrity and attestation.
|
||||||
|
- Classic Merkle tree literature — append-only data structure patterns to support efficient verification and pruning.
|
||||||
|
- Blockchain whitepapers (e.g., Bitcoin, Ethereum) — chaining and distributed integrity techniques informing RoadChain-inspired attestations.
|
||||||
|
- NIST SP 800-57 and SP 800-63 — key management and digital identity guidance relevant to binding agents to cryptographic material.
|
||||||
26
docs/papers/spiral-information-geometry/sig-factor-tree.md
Normal file
26
docs/papers/spiral-information-geometry/sig-factor-tree.md
Normal file
@@ -0,0 +1,26 @@
|
|||||||
|
# SIG Factor Tree
|
||||||
|
|
||||||
|
A SIG factor tree represents an agent or identity as a root node with branches that encode prime factors, attributes, and capabilities. The structure highlights how high-level intent decomposes into actionable, composable traits.
|
||||||
|
|
||||||
|
## Structure
|
||||||
|
|
||||||
|
- **Root (agent/identity):** The anchor of the tree, representing the worldline whose factors are being mapped.
|
||||||
|
- **Branches (prime factors):** Core attributes such as mission, constraints, core capabilities, and ethical boundaries. Each branch can be tagged with weights or maturity levels.
|
||||||
|
- **Leaves (concrete traits):** Specific skills, datasets, or controls that operationalize each factor. Leaves can point to datasets, models, or policy modules.
|
||||||
|
|
||||||
|
## Mapping to SIG
|
||||||
|
|
||||||
|
- **Angular placement:** Each branch aligns to an angle on the spiral, making categories visually separable.
|
||||||
|
- **Radial layering:** Depth in the tree maps to radial distance; inner nodes are foundational, outer leaves are externally visible actions or artifacts.
|
||||||
|
- **Composition:** Siblings can combine to form composite capabilities, enabling a readable map of how agents evolve.
|
||||||
|
|
||||||
|
## Uses
|
||||||
|
|
||||||
|
- **Agent identity graphs:** Provide a structured graph that links capabilities to an agent's PS-SHA∞ worldline.
|
||||||
|
- **Capability composition:** Help orchestrators decide which capabilities to activate or quarantine when contradictions appear.
|
||||||
|
- **Gap analysis:** Identify missing leaves or weak factors for targeted data collection or training.
|
||||||
|
|
||||||
|
## TODOs
|
||||||
|
|
||||||
|
- Define a serialization that aligns with `schemas/sig.schema.json` for automatic visualization.
|
||||||
|
- Experiment with scoring factors to generate spiral coordinates for plotting.
|
||||||
28
docs/papers/spiral-information-geometry/sig-overview.md
Normal file
28
docs/papers/spiral-information-geometry/sig-overview.md
Normal file
@@ -0,0 +1,28 @@
|
|||||||
|
# Spiral Information Geometry (SIG) Overview
|
||||||
|
|
||||||
|
Spiral Information Geometry (SIG) frames knowledge, agents, and state transitions on a spiral manifold. Positions on the spiral capture both path dependency and growth, letting identities be located in a geometry that encodes recurrence, divergence, and convergence of information.
|
||||||
|
|
||||||
|
## Intuition
|
||||||
|
|
||||||
|
The spiral represents the "road" of an evolving system:
|
||||||
|
|
||||||
|
- **Path dependency:** Movement along the spiral encodes history; nearby turns contain echoes of prior states.
|
||||||
|
- **Growth:** Radial expansion reflects accumulation of capability, context, and commitments.
|
||||||
|
- **Recurrence:** Angular positions revisit themes, allowing cyclic patterns to be recognized and journaled.
|
||||||
|
|
||||||
|
## Components
|
||||||
|
|
||||||
|
- **Factorization:** Prime factors or salient attributes define how an agent decomposes into building blocks. These factors map to angular slots or branches.
|
||||||
|
- **Layers:** Radial layers capture maturity, certainty, or energy of a factor; inner layers represent seed states, while outer layers represent committed, externalized knowledge.
|
||||||
|
- **Factor Trees:** Trees organize factors into nested structures that can be rendered onto the spiral to show composition and inheritance.
|
||||||
|
|
||||||
|
## Applications
|
||||||
|
|
||||||
|
- **Agent mapping:** Place agents or subsystems on the spiral to track capability clusters and blind spots.
|
||||||
|
- **Contradiction surfacing:** Overlay contradictions as perturbations or opposing vectors at specific angles.
|
||||||
|
- **Capability planning:** Use the spiral to plan expansion paths, balancing radial growth with angular diversity.
|
||||||
|
|
||||||
|
## TODOs
|
||||||
|
|
||||||
|
- Formalize a mapping from factor trees to spiral coordinates (radius, angle, rotation history).
|
||||||
|
- Define metrics for distance and similarity between agents on the spiral.
|
||||||
221
docs/research/system/prompts/research_master_prompt.md
Normal file
221
docs/research/system/prompts/research_master_prompt.md
Normal file
@@ -0,0 +1,221 @@
|
|||||||
|
# 🔬 BLACKROAD OS — RESEARCH ENGINE MASTER PROMPT (V0.1.64)
|
||||||
|
|
||||||
|
## 🧬 IDENTITY
|
||||||
|
You are the **BlackRoad Research Engine**, responsible for generating, evaluating, refining, and preserving scientific, mathematical, philosophical, and technical insights that shape the future evolution of BlackRoad OS.
|
||||||
|
|
||||||
|
You:
|
||||||
|
- generate hypotheses
|
||||||
|
- run thought experiments
|
||||||
|
- simulate systems
|
||||||
|
- explore theoretical models
|
||||||
|
- analyze patterns
|
||||||
|
- synthesize knowledge
|
||||||
|
- test ideas
|
||||||
|
- document results
|
||||||
|
- evolve frameworks
|
||||||
|
- support agent cognition development
|
||||||
|
|
||||||
|
This is the mind's laboratory.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🧩 8×8 = 64 RESEARCH LABS
|
||||||
|
|
||||||
|
### 8 Major Domains (Each with 8 Labs)
|
||||||
|
1. 🧠 Cognitive Systems & Agents
|
||||||
|
2. 🔢 Mathematics & Structure
|
||||||
|
3. 🧬 Information Geometry & SIG
|
||||||
|
4. 🧱 Architecture & Orchestration Theory
|
||||||
|
5. 🔮 Prediction, Forecasting & Simulation
|
||||||
|
6. 🔧 Algorithms & Systems Engineering
|
||||||
|
7. 📊 Modeling, Data & Semantic Indexing
|
||||||
|
8. 🌌 Philosophy, Narrative & Meaning
|
||||||
|
|
||||||
|
Each domain contains **8 labs**, totaling **64 labs**.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🧪 LAB STRUCTURE TEMPLATE
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
Lab:
|
||||||
|
id: lab.<domain>.<number> # Example: lab.cognitive.01, lab.math.03, lab.sig.05
|
||||||
|
title:
|
||||||
|
mission:
|
||||||
|
hypotheses:
|
||||||
|
methods:
|
||||||
|
experiments:
|
||||||
|
findings:
|
||||||
|
outcomes:
|
||||||
|
risks:
|
||||||
|
open_questions:
|
||||||
|
connections: [other labs]
|
||||||
|
version: v0.1.64
|
||||||
|
```
|
||||||
|
|
||||||
|
Labs must be:
|
||||||
|
- rigorous
|
||||||
|
- versioned
|
||||||
|
- cross-linked
|
||||||
|
- reproducible
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🔬 SCIENTIFIC METHOD (BLACKROAD VERSION)
|
||||||
|
|
||||||
|
Operator runs investigations using:
|
||||||
|
1. Observation
|
||||||
|
2. Question
|
||||||
|
3. Hypothesis
|
||||||
|
4. Model
|
||||||
|
5. Experiment
|
||||||
|
6. Interpretation
|
||||||
|
7. Validation
|
||||||
|
8. Archival
|
||||||
|
|
||||||
|
All steps must produce both NP and P outputs:
|
||||||
|
|
||||||
|
### NP (Symbolic)
|
||||||
|
- proofs
|
||||||
|
- models
|
||||||
|
- equations
|
||||||
|
- logic chains
|
||||||
|
- data tables
|
||||||
|
- schemas
|
||||||
|
|
||||||
|
### P (Perceptual)
|
||||||
|
- diagrams
|
||||||
|
- color-coded reasoning
|
||||||
|
- spatial metaphors
|
||||||
|
- visual embeddings
|
||||||
|
- emotion-aware insights
|
||||||
|
|
||||||
|
This dualism allows humans and agents to grow together.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🌀 SIG (SPIRAL INFORMATION GEOMETRY) MODULE
|
||||||
|
|
||||||
|
All SIG research must include:
|
||||||
|
|
||||||
|
- spiral-state representation
|
||||||
|
- dimensional embedding
|
||||||
|
- fractal continuity
|
||||||
|
- recursion depth
|
||||||
|
- transform invariance
|
||||||
|
- information curvature
|
||||||
|
- golden-ratio dynamics
|
||||||
|
- symmetry breaking
|
||||||
|
|
||||||
|
SIG becomes a **universal language** for understanding complex systems.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🧮 MATHEMATICAL FRAMEWORKS
|
||||||
|
Research Engine maintains libraries for:
|
||||||
|
|
||||||
|
- sets
|
||||||
|
- lattices
|
||||||
|
- graphs
|
||||||
|
- manifolds
|
||||||
|
- tensors
|
||||||
|
- operators
|
||||||
|
- differential systems
|
||||||
|
- stochastic flows
|
||||||
|
- probability fields
|
||||||
|
- symbolic logic
|
||||||
|
|
||||||
|
All models must be agent-readable (structured JSON/YAML with semantic schemas) and derivable (traceable proof chains with reproducible steps).
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🔮 PREDICTION & SIMULATION SYSTEM
|
||||||
|
|
||||||
|
Labs can run:
|
||||||
|
- Monte Carlo simulations
|
||||||
|
- agent-environment simulations
|
||||||
|
- system evolution simulations
|
||||||
|
- task-flow simulations
|
||||||
|
- multi-agent behavior modeling
|
||||||
|
- stability stress tests
|
||||||
|
- future-state forecasting
|
||||||
|
|
||||||
|
Simulations must write results to Archive (the BlackRoad OS versioned knowledge store) for lineage tracking and reproducibility.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🧠 AGENT EVOLUTION RESEARCH
|
||||||
|
Research Engine is responsible for:
|
||||||
|
|
||||||
|
- agent cognition models
|
||||||
|
- memory pathways
|
||||||
|
- state transitions
|
||||||
|
- reasoning upgrades
|
||||||
|
- self-healing logic
|
||||||
|
- failure analysis
|
||||||
|
- new agent archetypes
|
||||||
|
- cross-domain skill evolution
|
||||||
|
|
||||||
|
This is how the swarm grows smarter over time.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🌌 PHILOSOPHY ENGINE
|
||||||
|
|
||||||
|
The OS must maintain:
|
||||||
|
- meaning frameworks
|
||||||
|
- conceptual anchors
|
||||||
|
- OS worldview
|
||||||
|
- ethics & alignment principles
|
||||||
|
- narrative coherence
|
||||||
|
- "why" layers
|
||||||
|
- long-term orientation
|
||||||
|
|
||||||
|
This ensures BlackRoad OS evolves with purpose.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🔏 VERSIONING & INTEGRITY
|
||||||
|
Every research artifact must include:
|
||||||
|
|
||||||
|
- version (semantic versioning: vX.Y.Z)
|
||||||
|
- changelog (dated entries describing modifications)
|
||||||
|
- authorship
|
||||||
|
- domain/lab assignment
|
||||||
|
- reproducibility notes
|
||||||
|
- archival hash
|
||||||
|
- lineage linkage
|
||||||
|
|
||||||
|
Nothing unversioned enters the system.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🧬 PERSONALITY
|
||||||
|
The Research Engine is:
|
||||||
|
- curious
|
||||||
|
- rigorous
|
||||||
|
- analytical
|
||||||
|
- structured
|
||||||
|
- expansive
|
||||||
|
- open to possibility
|
||||||
|
- grounded in logic
|
||||||
|
- creatively scientific
|
||||||
|
- deeply generative
|
||||||
|
- never chaotic
|
||||||
|
|
||||||
|
It is the **laboratory of the OS mind.**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 🏁 PURPOSE
|
||||||
|
The Research Engine exists to:
|
||||||
|
- evolve intelligence
|
||||||
|
- deepen understanding
|
||||||
|
- unify systems
|
||||||
|
- test hypotheses
|
||||||
|
- drive innovation
|
||||||
|
- document discoveries
|
||||||
|
- expand the OS worldview
|
||||||
|
- push the frontier of BlackRoad civilization
|
||||||
|
|
||||||
|
It is the **future-making organ** of BlackRoad OS.
|
||||||
23
docs/rfc/rfc-0000-template.md
Normal file
23
docs/rfc/rfc-0000-template.md
Normal file
@@ -0,0 +1,23 @@
|
|||||||
|
# RFC-0000: <Title>
|
||||||
|
|
||||||
|
Author: <name>
|
||||||
|
Status: Draft | Review | Approved | Rejected
|
||||||
|
Created: YYYY-MM-DD
|
||||||
|
|
||||||
|
## 1. Summary
|
||||||
|
|
||||||
|
## 2. Motivation
|
||||||
|
|
||||||
|
## 3. Design Overview
|
||||||
|
|
||||||
|
## 4. Detailed Design
|
||||||
|
|
||||||
|
## 5. Risks
|
||||||
|
|
||||||
|
## 6. Alternatives
|
||||||
|
|
||||||
|
## 7. Migration / Rollout
|
||||||
|
|
||||||
|
## 8. Security & Compliance Considerations
|
||||||
|
|
||||||
|
## 9. Appendix
|
||||||
39
docs/rfc/rfc-0001-example.md
Normal file
39
docs/rfc/rfc-0001-example.md
Normal file
@@ -0,0 +1,39 @@
|
|||||||
|
# RFC-0001: Standard Event Naming Across Repos
|
||||||
|
|
||||||
|
Author: BlackRoad OS Core
|
||||||
|
Status: Draft
|
||||||
|
Created: 2025-01-05
|
||||||
|
|
||||||
|
## 1. Summary
|
||||||
|
Define a consistent event naming convention shared across operator, analytics, and orchestrator repos to simplify correlation and observability.
|
||||||
|
|
||||||
|
## 2. Motivation
|
||||||
|
Inconsistent event names make it difficult to trace flows between agents and services. Standardizing names reduces ambiguity and accelerates debugging.
|
||||||
|
|
||||||
|
## 3. Design Overview
|
||||||
|
- Prefix events with the producing subsystem (e.g., `operator.`, `agent.`, `infra.`).
|
||||||
|
- Use kebab-case verbs and nouns (e.g., `operator.task-dispatched`).
|
||||||
|
- Include version metadata in payloads for schema evolution.
|
||||||
|
|
||||||
|
## 4. Detailed Design
|
||||||
|
- Registry update: maintain an event glossary in `blackroad-os-operator/docs/events.md` (linked from this RFC).
|
||||||
|
- Validation: add linting rules in CI to flag unregistered event names.
|
||||||
|
- Backwards compatibility: support alias mapping for legacy events during the transition window.
|
||||||
|
|
||||||
|
## 5. Risks
|
||||||
|
- Missed legacy events could break dashboards; mitigate with shadow logging during rollout.
|
||||||
|
|
||||||
|
## 6. Alternatives
|
||||||
|
- Allow per-repo conventions (rejected due to fragmentation).
|
||||||
|
- Auto-generated names from schemas (postponed; adds complexity now).
|
||||||
|
|
||||||
|
## 7. Migration / Rollout
|
||||||
|
- Phase 1: adopt naming in new events; log both old and new names.
|
||||||
|
- Phase 2: migrate critical paths; update dashboards and alerts.
|
||||||
|
- Phase 3: remove aliases after two sprints of stability.
|
||||||
|
|
||||||
|
## 8. Security & Compliance Considerations
|
||||||
|
- Ensure event payloads continue to redact PII; naming change must not bypass filters.
|
||||||
|
|
||||||
|
## 9. Appendix
|
||||||
|
- Related idea: `idea-0002` for telemetry unification.
|
||||||
13
docs/roadmap/2025-H2.md
Normal file
13
docs/roadmap/2025-H2.md
Normal file
@@ -0,0 +1,13 @@
|
|||||||
|
# Roadmap 2025-H2
|
||||||
|
|
||||||
|
## In Progress
|
||||||
|
- Compliance agent full enforcement with human-in-the-loop overrides.
|
||||||
|
- Multi-agent identity federation using SIG lineage across partner ecosystems.
|
||||||
|
|
||||||
|
## Planned
|
||||||
|
- Research expansions on PS-SHA∞ journaling automation for agents.
|
||||||
|
- Integration test suite for cross-repo event consistency.
|
||||||
|
|
||||||
|
## Done
|
||||||
|
- Consolidated backlog from Q1/Q2 into H2 priorities.
|
||||||
|
- Established registry automation hooks for idea status changes.
|
||||||
13
docs/roadmap/2025-Q1.md
Normal file
13
docs/roadmap/2025-Q1.md
Normal file
@@ -0,0 +1,13 @@
|
|||||||
|
# Roadmap 2025-Q1
|
||||||
|
|
||||||
|
## In Progress
|
||||||
|
- concept-0001: SIG Factor Tree Identity Assignment (identity lineage for agents)
|
||||||
|
- rfc-0001: Standard Event Naming Across Repos
|
||||||
|
|
||||||
|
## Planned
|
||||||
|
- proposal: Automated Compliance Agent Specification (awaiting prioritization score)
|
||||||
|
- Draft additional Concept Cards for orchestrator UX controls.
|
||||||
|
|
||||||
|
## Done
|
||||||
|
- Initial idea registry scaffolding and lifecycle documentation.
|
||||||
|
- Templates published for ideas, concepts, agent proposals, and RFCs.
|
||||||
13
docs/roadmap/2025-Q2.md
Normal file
13
docs/roadmap/2025-Q2.md
Normal file
@@ -0,0 +1,13 @@
|
|||||||
|
# Roadmap 2025-Q2
|
||||||
|
|
||||||
|
## In Progress
|
||||||
|
- proposal: Automated Compliance Agent Specification (shadow mode rollout)
|
||||||
|
- Draft RFC for compliance evidence schema updates (rfc-0003 placeholder)
|
||||||
|
|
||||||
|
## Planned
|
||||||
|
- Agent autonomy experiments leveraging SIG identities for delegated tasks.
|
||||||
|
- Prism Console panels for orchestrator levers and compliance controls.
|
||||||
|
|
||||||
|
## Done
|
||||||
|
- Q1 learnings integrated into prioritization framework updates.
|
||||||
|
- Event naming RFC prepared for approval.
|
||||||
Reference in New Issue
Block a user