Technical Architecture

How DAHAO Works Under the Hood

The concepts, patterns, and integrations behind DAHAO’s client-orchestrated, versioned governance.

Core Architecture Overview

DAHAO is a file format and workflow pattern—not a server or agent. Your client reads the repo, renders a dry-run, and executes only after approval.

DAHAO Core Architecture

┌───────────────────────────────────────────────────────────────┐
│                         DAHAO CORE                            │
├───────────────────────────────────────────────────────────────┤
│  Terms (@)  →  Principles (#)  →  Rules  →  Meta-Rules        │
│    ↑               ↑                  ↑         ↑             │
│    └────────── Governs how all layers can change ─────────────┘
│                                                               │
│  Version-Controlled Governance Format                         │
│  Executed by Your Client (via MCP / APIs / Integrations)      │
│  Branches for Local Adaptation & Experimentation              │
└───────────────────────────────────────────────────────────────┘
Client-orchestrated via MCP

Your AI client is the MCP host: it holds your tokens, discovers tools, and executes propose-only actions after you approve.

Secure by default

Propose-only by default. Least-privilege scopes. No secrets in repos—tokens live in the client.

Evolvable semantics

Versioned terms and principles keep meaning precise while allowing branches to adapt safely.

The Four Layers Explained

@Terms — Living Definitions

Think of terms as versioned dictionary entries that you or your community can control:

@harm@2.0.0
= Versioned definition
In a wildlife branch, @harm@2.0.0 may add “habitat destruction”. The version stays the same; the branch provides context.

Why versioning matters: When rules reference @harm, they can pin a version for stability or follow a range for updates.

#Principles — Encoded Values

Principles are value statements built using Terms:

  • Use specific Term versions for clarity.
  • Not directly executable—Rules apply them.
  • Guide the creation and evaluation of Rules.
#minimize-harm = "Reduce @harm@2.0.0 to all @beings@1.0.0"
Rules — Declarative, Client-Orchestrated

Rules are declarative: they describe what should happen. Your client reads the rule, shows a dry-run plan, asks for approval, then calls your connected services (e.g., GitHub) under your authorization.

  • • Render a plan from the rule text.
  • • Request your approval (per step/session).
  • • Call existing tools (e.g., create a GitHub Discussion).
  • • Write back provenance (who/what/when/why).
Two authoring modes:
  • • Natural Language: write rules as you speak; reference @terms/#principles.
  • • Templates: adapt pre-built patterns for common scenarios.
Meta-Rules — System Evolution

Meta-rules govern how governance itself can change:

  • How to modify Terms (voting thresholds, discussion periods).
  • Rule precedence and conflict resolution.
  • Branch inheritance policies.
  • Immutable safety rules (what cannot change).

Version Control System

DAHAO treats governance like software development.

Version Format
1.2.0 — Minor (compatible additions)
1.2.1 — Patch (fixes/clarifications)
2.0.0 — Major (breaking changes)

Branches/forks carry context. The meaning of a term or rule may differ by branch without encoding it into the version string.

Key Features

Semantic Versioning

  • • Major: Breaking changes (2.0.0 → 3.0.0).
  • • Minor: New features (2.0.0 → 2.1.0).
  • • Patch: Bug fixes (2.0.0 → 2.0.1).

Branch Extensions

  • • Branches extend parent versions.
  • • Must maintain compatibility.
  • • Can propose changes upstream.

Operations

  • • Fork: Create a new branch with custom rules.
  • • Merge: Integrate successful innovations.
  • • Rollback: Instant restoration if something breaks.
  • • A/B Test: Try new versions with small groups.
Follow without Breakage
Depend on version ranges (e.g., ^1.2). Auto-accept MINOR/PATCH updates; MAJOR arrives as a review PR opened by a follower bot (propose-only). Idempotency markers prevent duplicate comments/PRs; rollbacks are fast.

Client-Orchestrated Integrations

Your client reads DAHAO rules, renders a plan, requests approval, and executes steps via your connected services.

Client-Orchestrated Execution Flow

┌────────────────────────────────────────────────────────────┐
│                         USER + CLIENT                      │
│  (ChatGPT / Claude / Copilot with user auth & tools)       │
└───────────────▲────────────────────────────────────────────┘
                │ reads spec, shows plan, asks approval
┌───────────────┴────────────────────────────────────────────┐
│                        DAHAO REPO                          │
│  Terms (@)  →  Principles (#)  →  Rules  ←  Meta-Rules     │
│  (versioned meaning & declarative intent; not executable)  │
└───────────────▲────────────────────────────────────────────┘
                │ executes approved steps via user's services
┌───────────────┴────────────────────────────────────────────┐
│                 Existing MCP-enabled Services              │
│     GitHub • Slack/Teams • Docs • Issue trackers • etc.    │
└────────────────────────────────────────────────────────────┘
Client Execution (Outbound)
  • Connect to MCP-enabled services.
  • Execute rules through your client.
  • Write provenance (who/what/when/why).
Service Integration (Inbound)
  • GitHub, Slack, Discord integrations.
  • Database and API connections.
  • Real-time event processing.
Defaults & Guardrails
  • Propose-only by default: agents draft plans; explicit approvals run actions.
  • Bounded auto-contribute (opt-in): reversible actions in allowed scopes (e.g., comments, draft PRs in your fork), with provenance, a kill switch, and time-bound consent.
  • No secrets in repo: tokens live in the client; repos stay clean.

Execution Flow (Client-Orchestrated)

How execution happens via your client.

Execution Pipeline
Trigger → Version/context check → Permission review → Render plan (dry-run)
↓
Execute Workflow Steps
↓
[Query] → [Analyze] → [Decide] → [Act]
↓
Audit Log → Result

Execution is performed by the user’s client calling existing services; DAHAO core is not a runtime.

Triggers

Event-based (new proposal, time-based, webhook) and condition matching (location, type, threshold).

Actions

Query data/APIs, run AI analysis, send notifications, update records, initiate votes.

Control Flow

Sequential, parallel, conditionals, loops—always with approvals or bounded auto-contribute.

Idempotency & Rollback
Operations carry idempotency markers (e.g., comment tags, branch naming) to avoid duplicates. Failures can retry safely or roll back. No silent merges.

Branch Architecture

Hierarchy model for governance evolution.

Core DAHAO (Universal principles)
    ├── Environmental Protection
    │   ├── Ocean Conservation
    │   ├── Wildlife Protection
    │   └── Climate Action
    ├── Technology Governance
    │   ├── AI Safety
    │   └── Open Source
    └── Your Custom Branch
Inheritance
  • • Start with parent’s Terms, Principles, Rules.
  • • Override or extend as needed.
  • • Maintain compatibility requirements.
Isolation
  • • Experiment without affecting parent.
  • • Propose merges upstream when ready.
  • • Custom MCP connections per branch.
Contribution
  • • Propose improvements upstream.
  • • Share successful innovations.
  • • Cross-pollinate ideas safely.

Security Architecture

Permission layers and security features.

Permissions are enforced by your client and the connected services you authorize. DAHAO repos never store secrets.

Permission Layers
System Level
    ├── User Permissions (read, write, admin)
    ├── Branch Permissions (member, moderator, owner)
    ├── Rule Permissions (which data, which services)
    └── MCP Permissions (per-service access control)
Scoped Access

Rules only access permitted data; MCP calls respect service limits; branch isolation enforced.

Audit Trail

Every action logged; immutable history; full traceability.

Rate Limiting

Per-user limits, per-service quotas, and cost controls.

Performance & Scaling

Optimization strategies for enterprise-scale governance.

These capabilities live in client apps and service integrations; DAHAO remains a simple, durable format.

Caching
  • • Cache MCP responses.
  • • Reuse analysis results.
  • • Version-aware invalidation.
Parallel Execution
  • • Independent steps run simultaneously.
  • • Distributed rule processing.
  • • Optimized workflows.
Resource Management
  • • Token limits for AI calls.
  • • Respect API rate limits.
  • • Enforce cost budgets.

Integration Patterns

For developers and organizations.

For Developers

Client Helper Patterns

  • • Parse DAHAO files → render a plan → request approval.
  • • Map rule intents to available MCP servers/tools.
  • • Execute with least-privilege scopes; write provenance back.
  • • Provide dry-run by default; support rollbacks.
For Organizations

Gradual Adoption

  • • Start with one department/project.
  • • Create a branch for experimentation.
  • • Connect existing tools via MCP.
  • • Expand as confidence grows.

Integration Points

  • • CI/CD pipelines (governance checks).
  • • Slack/Teams (notifications).
  • • Databases (data governance).
  • • AI tools (enhanced analysis).

Advanced Capabilities

Self-improvement, cross-branch learning, and future-ready design.

Self-Improvement

The system can modify its own modification process:

  • • Meta-rules govern rule changes.
  • • Community decides governance evolution.
  • • A/B testing for governance changes.
  • • Metrics-driven improvements.
Cross-Branch Learning
  • • Successful patterns spread.
  • • Failed experiments are contained.
  • • Best practices emerge.
  • • Network effects compound.
Technology Independent

DAHAO abstracts away the underlying technology:

  • • Integration layer: MCP, REST, GraphQL, or future protocols.
  • • AI abstraction: OpenAI, Claude, Llama, or what comes next.
  • • Storage agnostic: Git, blockchain, or emerging solutions.
  • • One constant: Your governance rules remain stable.
Summary

DAHAO’s architecture enables:

Living Governance — rules evolve; execution via your client.
Democratic Control — community-driven changes.
Universal Integration — your client connects to MCP-enabled services.
Safe Experimentation — branch isolation with upstream contribution.
Transparent Operation — full audit trail and version history.

Designed to be simple to use, powerful to extend, safe to experiment, and democratic to govern.

What’s Next

Building the future of governance together.

Technical Roadmap
Coming Soon

As we build DAHAO together, we’re planning:

  • • Git-based version control for all governance.
  • • Personal branches for customization.
  • • Automated GitHub workflows.
  • • Full technical documentation.
See Live GovernanceExplore Our Moral Code