The 4DA Framework

1. The Problem: Noise Is the Default

A working developer receives thousands of content signals per day — Hacker News posts, GitHub trending repos, RSS articles, Reddit threads, arXiv papers, security advisories, dependency updates. The existing tools for managing this flow all share the same flaw: they optimise for engagement, not relevance.

The result: developers either consume too much (noise fatigue) or too little (miss critical signals). Both outcomes are expensive.

4DA's thesis is simple: a machine that knows your codebase, your tech stack, your recent work, and your declared interests can reject the vast majority of content — 92% measured across 9 developer personas — and show you only what matters, without ever sending your data anywhere.

This requires three innovations:

1. A scoring algorithm that measures relevance across multiple dimensions simultaneously
2. A governance model that prevents the system from drifting, degrading, or creeping
3. An operational framework that keeps the system healthy autonomously

2. PASIFA: Privacy-Aware Scoring Intelligence

2.1 The Name

PASIFA — Privacy-Aware Semantic Intelligence Framework for Analysis.

PASIFA is not a machine learning model. It is a scoring philosophy: a structured methodology for determining whether a piece of content is relevant to a specific developer, using only information that exists locally on that developer's machine.

2.2 The Five Axes

Every piece of content is evaluated across five independent axes. Each axis answers a different question about relevance.

2.3 The Confirmation Gate

Raw scores are not enough. A content item might score highly on a single axis by coincidence — a keyword match that is syntactically relevant but semantically irrelevant.

PASIFA requires confirmation: at least two independent axes must agree that content is relevant before it is surfaced to the user.

With 0–1 confirming axes, content is heavily penalised — the ceiling ensures it cannot reach the relevance threshold regardless of any single strong signal. This is the mechanism behind the measured rejection rate: 92% of incoming content filtered as noise, 98% of actual noise correctly rejected, across 9 test personas.

Why this matters: Most recommendation systems optimise for recall (show more, miss less). PASIFA optimises for precision (show less, be right). A single false positive — irrelevant content surfaced to the user — erodes trust faster than ten correct recommendations build it.

2.4 The Scoring Pipeline

The V2 pipeline structures scoring into eight sequential phases:

2.5 Key Design Decisions

Why five axes, not one?

A single relevance score (e.g., cosine similarity of embeddings) is fragile. It captures semantic closeness but misses dependency relationships, recent work context, and learned preferences. Five axes provide triangulation — the same way a GPS needs multiple satellites to determine position accurately.

Why a confirmation gate, not a weighted sum?

A weighted sum allows one extremely high axis to overwhelm four irrelevant axes. The confirmation gate requires independent agreement. This is analogous to scientific peer review — a single strong result is interesting; two independent replications are convincing.

Why optimise for precision over recall?

Because the cost of false positives (irrelevant content shown) is asymmetrically higher than the cost of false negatives (relevant content missed). A missed article can be found later. An irrelevant article that wastes 30 seconds of attention can never be recovered. At scale, this asymmetry compounds into either trust or distrust.

Why local-only signals?

Because any signal that requires sending data externally introduces a privacy dependency that cannot be architecturally guaranteed. PASIFA uses only data that exists on the developer's machine — project files, git history, declared interests, feedback signals. This is not a limitation; it is the design.

2.6 Calibration and Compound Learning

PASIFA is not static. Three mechanisms enable the system to improve over time for each individual user:

1. Feedback Integration: Explicit signals (save, dismiss, mark irrelevant) and implicit signals (time spent, link clicks) adjust affinity scores for topics and sources. These adjustments have a 30-day half-life to prevent stale preferences from dominating.
2. Autophagy Calibration: The system periodically re-evaluates its own scoring accuracy by comparing predicted relevance against observed user behaviour. Calibration deltas are injected into the scoring context to correct systematic over- or under-scoring of specific topics.
3. Taste Embedding: A 384-dimensional vector representing the user's holistic preferences, computed as a weighted centroid of topic affinity embeddings. This enables semantic similarity scoring against the user's overall taste, not just individual topic matches.

All three mechanisms operate locally. No calibration data is transmitted externally. The result is a system that becomes more accurate for its specific user over time — a compound knowledge advantage that cannot be replicated by cloning the code.

3. The Authority Stack

3.1 The Problem It Solves

Software projects accumulate decisions over time. Without explicit governance, these decisions exist only in commit messages, pull request threads, and the memories of the people who made them. When those people leave, or when the project reaches sufficient complexity, decisions get re-litigated. The same arguments repeat. The same trade-offs are re-debated. Entropy increases.

The Authority Stack is a hierarchical governance framework that prevents this.

3.2 The Hierarchy

Higher always wins. A decision cannot violate an invariant. A convention cannot override a principle.

Invariants — The Constitution

Invariants are non-negotiable constraints. They define what the system MUST always do and MUST never do. They are not goals, preferences, or aspirations — they are structural guarantees.

Violation Protocol: If an invariant violation is discovered, all other work stops. The violation is documented, the impact is assessed, a minimal fix is created, a regression test is added, and FAILURE_MODES.md is updated. This protocol is itself non-negotiable.

Wisdom — The Operating Principles

Seven principles govern all development activity:

Zero Zones

Structural impossibilities that admit no override and no emergency exception:

Wisdom Gates

Decision checkpoints that trigger automatically:

Decisions — The Precedent Log

Every significant architectural decision is recorded with its rationale, alternatives considered, date, and status. This prevents re-litigation — the most insidious form of entropy in software projects.

Decisions can be superseded but never deleted. The history of reasoning is itself valuable — it shows what was tried, why it failed, and what constraints were active at the time.

Failure Modes — Institutional Memory

Every known failure pattern is catalogued with its severity, trigger conditions, mitigation strategy, and verification method. This document grows over time as the system encounters new failure modes.

Severity levels: CRITICAL HIGH MEDIUM LOW

The discipline is simple: every bug fix MUST check FAILURE_MODES.md for prior art, and every new failure pattern MUST be added. This creates an immune system that prevents the same class of bug from recurring.

3.3 Why This Works

• Re-litigation is expensive. Debating the same architectural question costs hours. DECISIONS.md makes the answer findable in seconds.
• Regressions are asymmetrically costly. One regression destroys more trust than ten features build. INVARIANTS.md prevents the regressions.
• Institutional memory is fragile. People forget, contexts change, teams turn over. The Authority Stack externalises memory into versioned documents.
• AI assistants need constraints. AI coding assistants are powerful but directionless without governance. The Authority Stack provides constitutional boundaries.

4. AOS: The Autonomous Operations System

4.1 The Problem

Even well-architected software degrades without active maintenance. Tests erode. Dependencies age. Dead code accumulates. Decision debt compounds. In traditional teams, this maintenance is distributed across team members. In a solo or small-team context, it must be systematised.

AOS (Autonomous Operations System) is a framework for measuring and maintaining system health autonomously.

4.2 The Sovereignty Score

A single number (0–100) that represents the system's current health, computed from 10 weighted components:

Thresholds:

The Sovereignty Score is not a vanity metric. It is a diagnostic tool — when it drops, the specific component that degraded tells you exactly where to focus.

4.3 Decision Delegation

Not all decisions require human judgment. AOS defines three tiers:

This delegation matrix is itself governed by the Authority Stack — it can be modified only through DECISIONS.md.

4.4 Operational Cadences

Health checks run at four frequencies:

• Session: Sovereignty delta, overdue cadences, escalation queue, immune scan
• Daily: Source health, build validation, test suite, file sizes, sovereignty score
• Weekly: Strategic drift detection, codebase metabolism, decision propagation, pre-launch checks
• Monthly: Decision replay, full invariant audit, wisdom crystallisation, dependency assessment, compound intelligence score

4.5 The Immune System

AOS includes a biological metaphor: antibodies. When a bug is fixed, an antibody is created — a pattern that can detect similar bugs elsewhere in the codebase.

When an antibody is created, it scans: (1) the module containing the fix, (2) all files importing from the fixed module, (3) all files in the same language. This creates a spreading immune response — each bug fix makes the system more resistant to the entire class of bug, not just the specific instance.

4.6 Compound Intelligence

AOS tracks whether the system is getting smarter over time through six metrics:

If the compound score increases month-over-month, the system is learning. If it decreases, something is degrading — and the specific component tells you what.

5. The Triad in Practice

PASIFA, the Authority Stack, and AOS are not independent systems. They form a closed loop:

• The Authority Stack defines what PASIFA must always do (invariants), how it should work (principles), and what has been decided (decisions)
• PASIFA operates within those constraints to score content for relevance
• AOS monitors PASIFA's health, detects degradation, and escalates when invariants are at risk
• Feedback from AOS operations (bugs found, patterns crystallised, decisions replayed) updates the Authority Stack

Each system makes the others more effective. The Authority Stack prevents PASIFA from drifting. AOS prevents the Authority Stack from becoming stale. PASIFA provides the scoring that AOS measures and maintains.

6. Privacy as Architecture, Not Policy

Most software claims privacy through policy: "We don't sell your data." "We use encryption." "Read our privacy policy."

4DA claims privacy through architecture: it is structurally impossible for data to leave the machine without the user's explicit action.

6.1 How This Is Enforced

6.2 Why Architecture Beats Policy

Policy depends on trust. The user must believe that the company will honour its promises. This trust is:

• Fragile — One breach destroys it
• Unverifiable — Users cannot audit a cloud service
• Revocable — Terms of service can change

Architecture depends on structure. The user can verify that data stays local by:

• Reading the CSP in the Tauri configuration
• Monitoring network traffic during operation
• Auditing the source code (FSL-1.1 makes it available)

Architecture-based privacy is a one-way door. Once you build a system that works without exfiltrating data, you cannot "accidentally" add telemetry — it would violate the CSP, the invariants, the pre-commit hooks, and the CI pipeline simultaneously.

7. The Compound Knowledge Thesis

The central thesis of 4DA is that a private intelligence system compounds knowledge in ways that cloud systems cannot.

7.1 Why Cloud Systems Plateau

Cloud recommendation systems improve by aggregating data across users. This creates a cold-start problem (new users get generic recommendations) and a convergence problem (all users eventually see similar content). The system converges toward the average user, not the individual.

7.2 Why Local Systems Compound

A local system that learns from one user's behaviour — their codebase, their feedback, their reading patterns, their git activity — develops an increasingly precise model of that individual's relevance function.

This precision compounds:

A competitor who clones the code gets the algorithm but not the calibration. A cloud competitor who aggregates across users gets breadth but not depth. The compound advantage is personal and non-transferable.

7.3 The Network Extension

The compound thesis extends to teams through encrypted metadata sharing:

• Each node (4DA instance) develops deep individual intelligence
• Metadata (not raw data) can be shared through encrypted relays
• Each node interprets shared metadata through its own local context
• The network becomes collectively smarter without any node sacrificing sovereignty

This is the "dumb relay, smart clients" architecture: the relay server sees only encrypted blobs. Intelligence is distributed. No single point of failure. No single point of surveillance.

8. Principles for Adoption

The 4DA Framework is published openly. These principles guide adoption:

For Tool Builders

1. Score, don't rank. Relevance is multi-dimensional. A single sorted list destroys the information that multiple axes provide. Show the user WHY something is relevant, not just THAT it is.
2. Gate, don't threshold. A simple score threshold allows single-axis flukes. A confirmation gate requires independent agreement. This is the difference between a heuristic and a methodology.
3. Govern, don't document. Documentation describes. Governance constrains. An invariant is not a "best practice" — it is a structural guarantee with a violation protocol.
4. Measure, don't assume. System health is not "it works" or "it doesn't." It is a score with components. When the score drops, the components tell you why.
5. Compound, don't aggregate. Individual depth beats collective breadth for personal relevance. Build systems that get smarter for one user, not systems that get average across many.

For Organisations

1. Build an Authority Stack. Start with invariants (what must never break), add principles (how you work), then decisions (what was chosen and why). This costs a day to set up and saves months of re-litigation.
2. Automate the immune system. Every bug fix should generate an antibody. Every antibody should scan the codebase. This turns each incident into a permanent defensive improvement.
3. Measure sovereignty. Define the components of your system's health. Weight them. Compute a score. Track it over time. When it drops, the component weights tell you where to focus.
4. Make privacy structural. If your system claims privacy, enforce it through architecture (CSP, keychain, local storage), not policy (privacy pages, terms of service). Architecture is verifiable. Policy is not.

For the Industry

If these ideas become the standard — if PASIFA-style multi-axis scoring, Authority Stack governance, and AOS operational frameworks become expected — then every tool that adopts them validates the approach. The industry moves toward privacy-first, structurally-governed, compound-knowledge systems.

That is the outcome we are building toward.

Appendix A: Glossary

Appendix B: Reference Implementation

The reference implementation of the 4DA Framework is the 4DA application itself:

• Source code: Available under FSL-1.1-Apache-2.0 license
• Scoring pipeline: src-tauri/src/scoring/ (14 modules, ~9,200 lines of Rust)
• Authority Stack: .ai/ directory (WISDOM.md, INVARIANTS.md, DECISIONS.md, FAILURE_MODES.md)
• AOS: .ai/OPS.md + scripts/ (21 validation and operational scripts)
• Website: 4da.ai