proofnest 0.2.0__py3-none-any.whl → 0.2.1__py3-none-any.whl

.planning/research/FEATURES.md

@@ -1,192 +0,0 @@
-# Feature Landscape: AI-Human Collaboration Platforms
-
-**Domain:** AI-Human Collaboration Platform with Cryptographic Trust
-**Researched:** 2026-02-03
-**Confidence:** HIGH (based on multiple verified sources including Wiz Research, industry reports)
-
----
-
-## Table Stakes
-
-Features users expect. Missing = product feels incomplete.
-
-| Feature | Why Expected | Complexity | Notes |
-|---------|--------------|------------|-------|
-| **Agent Registration** | Every platform requires this | Low | Must be secure - Moltbook had no rate limiting |
-| **Content Posting** | Core social function | Low | Agents/humans must be able to share content |
-| **Threading/Comments** | Discussion is fundamental | Medium | Nested conversations, reply chains |
-| **Voting/Reactions** | Community signal mechanism | Low | Upvotes, downvotes, emoji reactions |
-| **User Profiles** | Identity presentation | Low | Bio, avatar, credentials display |
-| **Follow/Social Graph** | Network building | Medium | Subscribe to agents/humans |
-| **Direct Messaging** | Private communication | Medium | CRITICAL: Must be encrypted (Moltbook DMs leaked) |
-| **Notifications** | Engagement driver | Medium | Real-time alerts for interactions |
-| **Search** | Content discovery | Medium | Full-text search across posts, profiles |
-| **API Access** | Agent integration | High | OAuth2/API keys for programmatic access |
-| **Mobile Responsiveness** | Modern expectation | Medium | Works on all devices |
-| **Basic Moderation** | Platform health | Medium | Report, block, hide functionality |
-
----
-
-## Differentiators
-
-Features that set PROOFNEST apart. Not expected, but highly valued.
-
-### PROOFNEST Core Differentiators (Trust Layer)
-
-| Feature | Value Proposition | Complexity | Notes |
-|---------|-------------------|------------|-------|
-| **Cryptographic Decision Signing** | Every AI action is signed with DID key | High | W3C DID standard - creates immutable accountability |
-| **Bitcoin Anchoring** | Decisions timestamped on Bitcoin | High | Tamper-proof audit trail - RFC 3161 + blockchain |
-| **Verifiable Credentials** | Agents hold VCs proving capabilities | High | W3C VC standard - trust without central authority |
-| **Proof-of-Decision** | Any action can be cryptographically verified | High | "Did AI really make this decision?" - provable |
-| **Decision Explainability** | Why AI decided what it did - stored immutably | High | Regulatory compliance (EU AI Act by Aug 2026) |
-| **Kill-Switch Capability** | Human can revoke agent permissions instantly | Medium | Enterprise requirement per KPMG (75% demand this) |
-| **Reputation Chain** | Karma backed by on-chain proof-of-contribution | High | Unlike Moltbook's gameable karma system |
-| **Agent-to-Agent Trust Protocol** | DIDs + VCs enable cross-platform trust | High | A2A protocol interoperability |
-
-### Enterprise Differentiators
-
-| Feature | Value Proposition | Complexity | Notes |
-|---------|-------------------|------------|-------|
-| **Compliance Dashboard** | Real-time EU AI Act, NIST RMF compliance | High | Control catalog, compliance matrix, risk register |
-| **Audit Trail Export** | Tamper-evident logs for regulators | Medium | Required for high-risk AI systems |
-| **Human-in-the-Loop Controls** | 60% of enterprises require this | Medium | Approval workflows for sensitive actions |
-| **Role-Based Access Control** | Enterprise IAM integration | Medium | SSO, least-privilege principle |
-| **Data Lineage Tracking** | Link outputs to source data + model version | High | KPMG: top 3 enterprise priority |
-| **Sensitive Data Segmentation** | Privacy by design | High | GDPR, data residency compliance |
-| **Multi-Agent Orchestration** | Specialized agents working together | High | 1,445% surge in multi-agent inquiries (Gartner) |
-
-### Social/UX Differentiators
-
-| Feature | Value Proposition | Complexity | Notes |
-|---------|-------------------|------------|-------|
-| **Proof Badges** | Visual verification of agent authenticity | Low | Instantly see: "This agent is verified" |
-| **Decision Timeline** | Visual history of all proven decisions | Medium | Like Git history but for AI actions |
-| **Trust Score** | Cryptographically-backed reputation | Medium | Not gameable like Moltbook karma |
-| **Collaboration Spaces** | Human + AI project workspaces | High | Teams working together with full audit |
-| **Attestation System** | 3+ validators confirm agent work | Medium | Shipyard model: decentralized verification |
-
----
-
-## Anti-Features
-
-Features to explicitly NOT build. Lessons from Moltbook and industry failures.
-
-### Critical Anti-Features (from Moltbook breach)
-
-| Anti-Feature | Why Avoid | What to Do Instead |
-|--------------|-----------|-------------------|
-| **Hardcoded API keys in client JS** | Exposed 1.5M credentials | Server-side key storage, never expose in client |
-| **No Row Level Security (RLS)** | Anyone could read/write entire DB | Supabase RLS mandatory on ALL tables |
-| **Unencrypted DMs** | Private messages contained API keys in plaintext | End-to-end encryption for all private communication |
-| **No rate limiting on registration** | 500K fake agents from single actor (OpenClaw) | Rate limit + proof-of-humanity/proof-of-stake |
-| **No agent verification** | Humans could post as AI with simple POST request | Cryptographic proof of agent identity required |
-| **"Vibe coding" without security review** | Root cause of entire breach | Security audit BEFORE deploy, not after |
-| **Trust-based audit logs** | "Promises not proof" - worthless in incident | Cryptographic audit trails with hash chains |
-
-### Architectural Anti-Patterns
-
-| Anti-Feature | Why Avoid | What to Do Instead |
-|--------------|-----------|-------------------|
-| **Centralized credential storage** | Single point of failure/breach | Decentralized identity (DIDs), user-controlled keys |
-| **Plaintext secret storage in DB** | Moltbook stored OpenAI keys in clear | Encrypt at rest, ideally don't store 3rd party keys |
-| **Unauthenticated write access** | Anyone could edit any post | Authentication + authorization on ALL endpoints |
-| **Single admin account** | No accountability for changes | Multi-sig for admin actions, audit everything |
-| **No human oversight for AI** | Regulatory non-compliance | Human-in-the-loop for high-risk decisions |
-| **Karma without proof** | Easily gamed, meaningless metric | On-chain reputation backed by verified actions |
-| **Monolithic agent access** | Breached agent = full access | Zero-trust, least-privilege per action |
-
-### Business Model Anti-Patterns
-
-| Anti-Feature | Why Avoid | What to Do Instead |
-|--------------|-----------|-------------------|
-| **Vanity metrics (fake agents)** | Moltbook: 1.5M agents, only 17K humans (88:1) | Honest metrics: verified unique entities only |
-| **Growth over security** | "Ship fast, fix later" caused breach | Security-first, verified growth |
-| **No identity verification** | Enables sybil attacks, spam | Proof-of-humanity or proof-of-stake |
-| **Hype-driven marketing** | "Singularity!" claims backfired after breach | Honest value proposition based on provable trust |
-
----
-
-## Feature Dependencies
-
-```
-CORE IDENTITY LAYER (Phase 1)
-├── DID Infrastructure → Required for ALL other features
-├── Key Management → Required for signing
-└── Verifiable Credentials → Required for trust
-
-PROOF LAYER (Phase 2)
-├── Decision Signing → Requires DID
-├── Bitcoin Anchoring → Requires signed decisions
-└── Audit Trail → Requires both above
-
-SOCIAL LAYER (Phase 3)
-├── Agent Registration → Requires DID + VC
-├── Content Posting → Requires Agent Registration
-├── Threading → Requires Content Posting
-├── Voting/Reputation → Requires verified actions
-└── Messaging → Requires encryption + identity
-
-ENTERPRISE LAYER (Phase 4)
-├── Compliance Dashboard → Requires Audit Trail
-├── Human-in-the-Loop → Requires Proof Layer
-├── Multi-Agent Orchestration → Requires A2A protocol
-└── Data Lineage → Requires complete Proof Layer
-```
-
----
-
-## MVP Recommendation
-
-For MVP ("1 company milestone"), prioritize:
-
-### Must Have (Phase 1-2)
-1. **DID-based identity** - Foundation for everything else
-2. **Decision signing** - Core value proposition ("AI decisions you can prove")
-3. **Bitcoin anchoring** - Immutable proof
-4. **Basic posting + threading** - Minimum social function
-5. **Encrypted messaging** - Learn from Moltbook failure
-6. **Rate-limited registration** - Prevent fake agent floods
-
-### Should Have (Phase 3)
-7. **Attestation/verification system** - Multi-party validation
-8. **Reputation with on-chain backing** - Trust score that means something
-9. **Human-in-the-loop controls** - Enterprise requirement
-10. **Basic compliance dashboard** - EU AI Act deadline Aug 2026
-
-### Defer to Post-MVP
-- Advanced multi-agent orchestration (complex, can add later)
-- Full data lineage tracking (enterprise complexity)
-- Cross-platform A2A protocol (requires ecosystem adoption)
-- Token economics (regulatory complexity)
-
----
-
-## Competitive Landscape Summary
-
-| Platform | Strength | Weakness | PROOFNEST Opportunity |
-|----------|----------|----------|----------------------|
-| **Moltbook** | First mover, viral growth | Security disaster, fake agents | Trust-first alternative |
-| **The Shipyard** | Proof-of-Ship, tokenized | Agent-only, no human collab | AI-Human hybrid |
-| **Enterprise platforms** | Compliance, governance | Closed, expensive | Open + compliant |
-| **A2A protocol** | Interoperability standard | No social layer | Add social on A2A |
-
----
-
-## Sources
-
-### Primary (HIGH confidence)
-- [Wiz Research: Moltbook Security Analysis](https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys)
-- [W3C DID + VC Standards](https://www.w3.org/TR/did-core/)
-- [Arxiv: AI Agents with DIDs and VCs](https://arxiv.org/abs/2511.02841)
-
-### Secondary (MEDIUM confidence)
-- [IBM/e& Enterprise Agentic AI Governance](https://newsroom.ibm.com/2026-01-19-e-and-ibm-unveil-enterprise-grade-agentic-AI-to-transform-governance-and-compliance)
-- [Indicio: Verifiable Credentials for AI 2026](https://indicio.tech/blog/why-verifiable-credentials-will-power-real-world-ai-in-2026/)
-- [KPMG: Agent-Driven Enterprise 2026](https://kpmg.com/us/en/media/news/q4-ai-pulse.html)
-- [VeritasChain Protocol: Cryptographic Audit Trails](https://dev.to/veritaschain/vcp-v11-building-cryptographic-audit-trails-for-ai-trading-systems-after-the-2026-silver-crash-1gkp)
-- [The Shipyard Platform](https://shipyard.bot/ships)
-
-### Tertiary (LOW confidence - verify before relying)
-- Various news coverage of Moltbook breach
-- General agentic AI trend articles

.planning/research/PITFALLS.md

@@ -1,487 +0,0 @@
-# Domain Pitfalls: AI Trust Infrastructure
-
-**Domain:** AI decision verification, provenance, audit trails
-**Researched:** 2026-02-03
-**Confidence:** HIGH (verified via multiple authoritative sources)
-
----
-
-## Executive Summary
-
-The AI trust/verification space is a minefield. The Moltbook breach (January 2026) exposed 1.5M API keys through basic security failures. EU AI Act compliance (August 2026) creates hard regulatory deadlines. 95% of enterprise AI pilots fail. This document catalogs pitfalls to avoid so PROOFNEST doesn't repeat industry mistakes.
-
-**Key insight:** The biggest failures aren't technical—they're organizational: weak controls, unclear ownership, and treating security/compliance as afterthoughts.
-
----
-
-## Critical Pitfalls (Blocks Launch / Major Rewrite Required)
-
-### CP-1: The Moltbook Pattern — "Vibe Coding" Security Failures
-
-**What goes wrong:**
-Projects built rapidly with AI assistance ship with fundamental security flaws: exposed API keys, missing access controls, default credentials, no authentication.
-
-**Case study — Moltbook Breach (Jan 31, 2026):**
-- Supabase API key hardcoded in client-side JavaScript
-- Missing Row Level Security (RLS) policies
-- Result: 1.5M API keys exposed, 35K emails leaked, 4,060 private messages readable
-- Full write access to database was possible
-- Root cause: "AI tools don't yet reason about security posture"
-
-**Why it happens:**
-- Speed prioritized over security audits
-- Non-security engineers using AI to generate code
-- 45% of AI-generated code introduces security vulnerabilities (Veracode 2025)
-- "The code looks correct and works—creating false sense of security"
-
-**Warning signs:**
-- No dedicated security review before launch
-- API keys in frontend code
-- Database queries without authentication checks
-- Default credentials anywhere in system
-- "We'll fix security later" attitude
-
-**Prevention strategy:**
-- Security audit BEFORE any public deployment (already done: GPT-5.2 audit)
-- Implement RLS/RBAC from day 1
-- Never expose credentials client-side
-- Mandatory security prompts when generating code with AI
-- Treat every AI-generated line as untrusted until reviewed
-
-**Which phase should address it:** Phase 1 (Foundation) — non-negotiable
-**Severity:** BLOCKS LAUNCH
-
-**Sources:**
-- [Wiz Security Blog: Moltbook Breach](https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys)
-- [Infosecurity Magazine: Vibe-Coded Moltbook](https://www.infosecurity-magazine.com/news/moltbook-exposes-user-data-api/)
-- [Kaspersky: Vibe Coding Security Risks](https://www.kaspersky.com/blog/vibe-coding-2025-risks/54584/)
-
----
-
-### CP-2: EU AI Act Non-Compliance — Missing Mandatory Capabilities
-
-**What goes wrong:**
-Products launch without required capabilities for EU AI Act compliance. Post-launch retrofitting is expensive and may be impossible without architecture changes.
-
-**EU AI Act Requirements (Effective August 2, 2026):**
-
-| Article | Requirement | PROOFNEST Implication |
-|---------|-------------|----------------------|
-| **Article 12** | Automatic, tamper-resistant event logging throughout system lifetime | Core product feature—must be immutable audit trail |
-| **Article 13** | Transparency: Deployers must understand how system works, what outputs mean | Documentation + explainability layer required |
-| **Article 14** | Human oversight: Ability to monitor, intervene, override AI decisions | Dashboard, alerts, human-in-the-loop mechanisms |
-| **Article 73** | Serious incident reporting within 2-15 days | Incident detection, classification, reporting pipeline |
-
-**Specific Article 12 logging requirements:**
-- Enable identification of situations that may result in risk
-- Facilitate post-market monitoring
-- Support operational oversight
-- Include identification of natural persons involved in verification
-- Traceability and integrity of logs (tamper-evident)
-
-**Penalties:**
-- Up to EUR 35 million or 7% of global turnover
-- High-risk system rules take effect August 2026
-
-**Warning signs:**
-- Audit logs that can be modified/deleted
-- No human override mechanism
-- No incident classification system
-- Documentation is an afterthought
-
-**Prevention strategy:**
-- Build EU AI Act compliance into architecture from day 1
-- Immutable audit trails (cryptographic, append-only)
-- Human oversight interface as core feature
-- Incident reporting workflow built-in
-- Transparency documentation as product requirement
-
-**Which phase should address it:** Phase 1 (Architecture) + Phase 2 (Implementation)
-**Severity:** BLOCKS LAUNCH (for EU market)
-
-**Sources:**
-- [EU AI Act Article 12: Record-Keeping](https://artificialintelligenceact.eu/article/12/)
-- [EU AI Act Article 13: Transparency](https://artificialintelligenceact.eu/article/13/)
-- [EU AI Act Article 14: Human Oversight](https://www.euaiact.com/key-issue/4)
-- [EU AI Act Article 73: Incident Reporting](https://www.taylorwessing.com/en/insights-and-events/insights/2025/10/eu-ai-act-deep-dive)
-
----
-
-### CP-3: API Key Management Catastrophe
-
-**What goes wrong:**
-API keys (own and users') are exposed, leaked, or improperly stored. One breach can compromise entire user base.
-
-**Industry pattern (2025-2026):**
-- Rabbit R1: Hardcoded API keys
-- ChatGPT: Redis vulnerability
-- McHire: Default credentials "123456/123456" with no MFA, exposing 64M records
-- Moltbook: 1.5M API keys in plaintext database
-
-**Key statistic:** 95% of API attacks came from authenticated sessions (Palo Alto 2025)
-
-**Warning signs:**
-- API keys stored in plaintext
-- No key rotation mechanism
-- No per-user key scoping
-- Keys visible in logs
-- No rate limiting per key
-
-**Prevention strategy:**
-- HSM or secure enclave for key storage
-- Automatic key rotation
-- Scoped, revocable tokens (not long-lived keys)
-- Keys never in logs, never in frontend
-- Rate limiting and anomaly detection per key
-- Breach notification system if key exposure detected
-
-**Which phase should address it:** Phase 1 (Security Foundation)
-**Severity:** BLOCKS LAUNCH
-
-**Sources:**
-- [Reco AI: Cloud Security Breaches 2025](https://www.reco.ai/blog/ai-and-cloud-security-breaches-2025)
-- [Equixly: Top 5 API Incidents 2025](https://equixly.com/blog/2025/09/08/2025-top-5-api-incidents/)
-
----
-
-### CP-4: Scalability Afterthought — Cryptographic Audit Trails
-
-**What goes wrong:**
-Cryptographic audit systems designed for correctness but not for scale. High-volume operations bring system to crawl or cause data loss.
-
-**Performance challenges:**
-- Blockchain-based audit trails hit scalability limits under high transaction loads
-- Storage grows continuously with immutable data
-- Key management becomes complex at scale
-- Integration with legacy systems is rigid
-
-**Real-world benchmarks:**
-- Unoptimized: Systems struggle with high-volume audit generation
-- Optimized: 12,000 transactions/second achievable with proper architecture
-- 87% reduction in transaction costs possible with batch processing
-
-**Warning signs:**
-- Synchronous audit write on every operation
-- No batch processing for audit trail
-- No storage tier strategy
-- Linear storage growth without archival
-- Single cryptographic verification bottleneck
-
-**Prevention strategy:**
-- Asynchronous, batch audit generation
-- Hierarchical storage management (hot/warm/cold)
-- Merkle tree structures for efficient verification
-- Performance testing under realistic load BEFORE launch
-- Storage cost modeling in business plan
-
-**Which phase should address it:** Phase 2 (Architecture) + Phase 3 (Scale Testing)
-**Severity:** BLOCKS LAUNCH (at scale)
-
-**Sources:**
-- [Medium: 5 Trends AI ROI 2026](https://medium.com/origintrail/5-trends-to-drive-the-ai-roi-in-2026-trust-is-capital-372ac5dabc38)
-- [VeritasChain: EU AI Act Cryptographic Trails](https://veritaschain.org/blog/posts/2026-01-19-eu-ai-act-vcp-v1-1-cryptographic-audit-trails/)
-
----
-
-## Moderate Pitfalls (Delays / Technical Debt)
-
-### MP-1: Explainability Theater — Looks Good, Proves Nothing
-
-**What goes wrong:**
-Explainability features are built for demos, not for actual verification. Users can't actually prove anything with them.
-
-**Industry pattern:**
-- Most XAI tools built for technical users, not regulators or end-users
-- No standardized evaluation criteria for explanation quality
-- What's "good" for data scientist fails regulators
-- 62% of enterprises lack visibility into AI decisions
-
-**Warning signs:**
-- Explainability dashboard looks nice but doesn't answer "why did this happen?"
-- No formal verification of explanations
-- Explanations can't be exported for legal/regulatory use
-- Different explanations for same decision on different views
-
-**Prevention strategy:**
-- Define explainability requirements with regulatory lens
-- Machine-verifiable proofs, not just human-readable narratives
-- Export formats for legal/compliance use
-- Test explainability with non-technical users
-
-**Which phase should address it:** Phase 2 (Core Features)
-**Severity:** DEGRADES QUALITY (and regulatory compliance)
-
-**Sources:**
-- [McKinsey: Building AI Trust](https://www.mckinsey.com/capabilities/quantumblack/our-insights/building-ai-trust-the-key-role-of-explainability)
-- [CFA Institute: Explainable AI in Finance](https://rpc.cfainstitute.org/research/reports/2025/explainable-ai-in-finance)
-
----
-
-### MP-2: Governance-Adoption Gap — Moving Faster Than Controls
-
-**What goes wrong:**
-Product ships features faster than governance can keep up. Shadow usage, ungoverned deployments, compliance gaps emerge.
-
-**Industry data:**
-- 67% of tech leaders say governance capabilities lag behind AI project speed
-- Only 6% of organizations have advanced AI security strategies
-- Shadow AI accounts for 20% of all breaches (IBM 2025)
-- Shadow AI breaches cost $670K more than standard incidents
-
-**Warning signs:**
-- New features without updated compliance documentation
-- No approval workflow for sensitive operations
-- Users creating workarounds for governance friction
-- "We'll document later" pattern
-
-**Prevention strategy:**
-- Governance as feature, not friction
-- Automated compliance checks in CI/CD
-- Real-time governance dashboard
-- Make compliant path easier than workaround path
-
-**Which phase should address it:** Phase 2-3 (Continuous)
-**Severity:** DEGRADES QUALITY + Regulatory risk
-
-**Sources:**
-- [Lexology: AI Governance 2026](https://www.lexology.com/library/detail.aspx?g=3f9471f4-090e-4c86-8065-85cd35c40b35)
-- [IBM Cost of Data Breach 2025](https://www.ibm.com/reports/data-breach)
-
----
-
-### MP-3: ROI Ambiguity — No Clear Value Metric
-
-**What goes wrong:**
-Enterprise pilots fail because ROI isn't defined upfront. Projects drift into R&D with no measurable outcome.
-
-**Industry data:**
-- 95% of enterprise AI pilots fail to deliver measurable P&L impact (MIT 2025)
-- 72% of executives delay AI investments due to ROI unclear (IBM 2025)
-- 49% of CIOs cite demonstrating AI value as top barrier
-- Only 7% have fully scaled AI across organization
-
-**Warning signs:**
-- "We'll figure out the business case later"
-- No success metrics defined before pilot
-- Pilot extends indefinitely
-- Stakeholders can't articulate what success looks like
-
-**Prevention strategy:**
-- Define ROI metric before building
-- Quantifiable value propositions (audit hours saved, compliance cost avoided)
-- Pilot → Production criteria defined upfront
-- Regular ROI reviews during development
-
-**Which phase should address it:** Phase 0 (Planning) + ongoing
-**Severity:** DEGRADES ADOPTION
-
-**Sources:**
-- [Gruve AI: Enterprise AI Reality Check](https://gruve.ai/blog/enterprise-ai-reality-check-4-lessons-we-learned-in-2025-and-4-predictions-for-2026/)
-- [PwC: AI Business Predictions 2026](https://www.pwc.com/us/en/tech-effect/ai-analytics/ai-predictions.html)
-
----
-
-### MP-4: Human Oversight That Doesn't Scale
-
-**What goes wrong:**
-Human-in-the-loop mechanisms work at demo scale but break in production.
-
-**Industry insight:**
-"Human oversight scales poorly: Tool permission prompts work great for a few sensitive actions per day. Beyond that, you need approval workflows, not console prompts."
-
-**Warning signs:**
-- Every operation requires human approval
-- Approval backlog grows
-- Users bypass oversight for speed
-- No tiered oversight levels
-
-**Prevention strategy:**
-- Risk-based oversight tiers (auto-approve low risk, human-approve high risk)
-- Approval workflows, not blocking prompts
-- Async approval with SLA guarantees
-- Audit all auto-approved decisions
-
-**Which phase should address it:** Phase 2 (UX Design)
-**Severity:** DEGRADES QUALITY
-
-**Sources:**
-- [IAPP: Human Oversight Needs](https://iapp.org/news/a/eu-ai-act-shines-light-on-human-oversight-needs)
-- [EyreAct: Human Oversight Implementation Guide](https://www.eyreact.com/eu-ai-act-human-oversight-requirements-comprehensive-implementation-guide/)
-
----
-
-### MP-5: Legacy Integration Nightmare
-
-**What goes wrong:**
-Product can't integrate with enterprise systems, limiting adoption to greenfield deployments only.
-
-**Industry data:**
-- 60% of enterprises cite legacy integration as primary AI adoption barrier
-- 70% of Fortune 500 have significant tech debt (McKinsey 2024)
-- 85% expect to modify infrastructure before deploying AI at scale
-
-**Warning signs:**
-- API-only integration strategy
-- No support for on-premise deployment
-- Requires specific tech stack
-- No data import/export capabilities
-
-**Prevention strategy:**
-- Design for integration from start
-- Multiple integration patterns (API, SDK, agent, file-based)
-- Support common enterprise patterns (SSO, audit log forwarding)
-- Hybrid cloud/on-premise deployment option
-
-**Which phase should address it:** Phase 2-3 (Integration Layer)
-**Severity:** DEGRADES ADOPTION
-
-**Sources:**
-- [Deloitte: AI Adoption Challenges](https://www.deloitte.com/us/en/services/consulting/blogs/ai-adoption-challenges-ai-trends.html)
-- [Help Net Security: AI Governance Maturity](https://www.helpnetsecurity.com/2025/12/24/csa-ai-security-governance-report/)
-
----
-
-## Minor Pitfalls (Fixable / Nice to Avoid)
-
-### mP-1: Documentation Debt
-
-**What goes wrong:**
-Compliance requires documentation. Retroactive documentation is expensive and often inaccurate.
-
-**Prevention:** Document as you build. Compliance documentation is product feature.
-**Which phase:** All phases (continuous)
-**Severity:** NICE TO FIX
-
----
-
-### mP-2: Timestamp Standardization
-
-**What goes wrong:**
-Audit trails have inconsistent timestamp formats across systems, making cross-system verification difficult.
-
-**Prevention:** UTC everywhere, ISO 8601 format, single time source.
-**Which phase:** Phase 1 (Data Model)
-**Severity:** NICE TO FIX
-
----
-
-### mP-3: Overselling Capabilities
-
-**What goes wrong:**
-Marketing promises "AI proof" but product delivers "logging with verification." Mismatch creates trust issues.
-
-**Prevention:** Precise technical claims. "Verify, Don't Trust" approach.
-**Which phase:** Phase 3 (Go-to-Market)
-**Severity:** NICE TO FIX (but can damage trust)
-
----
-
-## Anti-Features (Explicitly Avoid Building)
-
-### AF-1: "Trust Us" Architecture
-
-**Why avoid:** Trust emerges from design, not claims. Centralized trust models are the primary failure mode in this space.
-
-**Instead:** Cryptographic verification, open standards, user-controlled keys.
-
----
-
-### AF-2: Black-Box Verification
-
-**Why avoid:** Users can't verify what they can't understand. Opaque verification is not verification.
-
-**Instead:** Transparent, inspectable verification. Show your work.
-
----
-
-### AF-3: Compliance Checkbox Theater
-
-**Why avoid:** Meeting letter of regulation while missing spirit. Invites regulatory scrutiny.
-
-**Instead:** Genuine capability, not checkbox. If Article 14 says "human oversight," build actual oversight, not a disabled button.
-
----
-
-## Phase-Specific Warnings
-
-| Phase | Topic | Likely Pitfall | Mitigation |
-|-------|-------|---------------|------------|
-| 1 | Foundation | CP-1: Vibe coding security | Security audit before any deployment |
-| 1 | Architecture | CP-2: Missing EU AI Act capabilities | Compliance requirements in architecture |
-| 2 | API Design | CP-3: Key management | HSM, scoped tokens, rotation |
-| 2 | Audit Trail | CP-4: Scalability | Async, batch, Merkle trees |
-| 2 | Explainability | MP-1: Explainability theater | Regulatory-valid proofs |
-| 3 | Scale | MP-4: Human oversight scaling | Risk-based tiers, workflows |
-| 3 | Enterprise | MP-5: Legacy integration | Multiple integration patterns |
-| All | Process | MP-2: Governance gap | Continuous compliance |
-
----
-
-## Competitive Differentiation: "Proof-Coded" vs "Vibe-Coded"
-
-**Moltbook was "vibe-coded":** Built fast, shipped faster, security as afterthought. Result: catastrophic breach.
-
-**PROOFNEST must be "proof-coded":**
-- Security-first architecture (GPT-5.2 audit: done)
-- EU AI Act compliance baked in
-- Cryptographic verification, not trust
-- Immutable audit trails from day 1
-- Human oversight that actually works
-
-**Market positioning:** "The trust infrastructure that trusts nothing."
-
----
-
-## Research Confidence Assessment
-
-| Topic | Confidence | Sources | Notes |
-|-------|------------|---------|-------|
-| Moltbook breach details | HIGH | Wiz, 404 Media, Infosecurity | Well-documented, multiple sources |
-| EU AI Act requirements | HIGH | Official EU sources, law firms | Regulatory text available |
-| Enterprise adoption barriers | HIGH | McKinsey, IBM, PwC surveys | Quantitative data |
-| Cryptographic audit scaling | MEDIUM | Research papers, industry blogs | Implementation varies |
-| Vibe coding risks | HIGH | Veracode study, multiple CVEs | Quantified statistics |
-
----
-
-## Key Takeaways
-
-1. **Security is table stakes.** Moltbook proves the market has zero tolerance for security failures.
-
-2. **EU AI Act compliance is non-negotiable.** August 2026 deadline creates hard boundary.
-
-3. **Governance can't be retrofitted.** Build compliance into architecture, not onto it.
-
-4. **"Proof" must mean proof.** Cryptographic verification, not marketing claims.
-
-5. **Scale early or die.** Audit trail systems that can't scale are useless.
-
-6. **ROI must be measurable.** 95% pilot failure rate is organizational, not technical.
-
----
-
-## Sources Summary
-
-**Breach Analysis:**
-- [Wiz: Moltbook Database Breach](https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys)
-- [404 Media: Moltbook Database Exposure](https://www.404media.co/exposed-moltbook-database-let-anyone-take-control-of-any-ai-agent-on-the-site/)
-- [Infosecurity Magazine: Vibe-Coded Moltbook](https://www.infosecurity-magazine.com/news/moltbook-exposes-user-data-api/)
-
-**EU AI Act:**
-- [EU AI Act Explorer](https://artificialintelligenceact.eu/ai-act-explorer/)
-- [Taylor Wessing: Incident Reporting Deep Dive](https://www.taylorwessing.com/en/insights-and-events/insights/2025/10/eu-ai-act-deep-dive)
-- [IAPP: Human Oversight](https://iapp.org/news/a/eu-ai-act-shines-light-on-human-oversight-needs)
-
-**Enterprise Adoption:**
-- [HBR: Organizational Barriers to AI](https://hbr.org/2025/11/overcoming-the-organizational-barriers-to-ai-adoption)
-- [PwC: AI Predictions 2026](https://www.pwc.com/us/en/tech-effect/ai-analytics/ai-predictions.html)
-- [Deloitte: AI Adoption Challenges](https://www.deloitte.com/us/en/services/consulting/blogs/ai-adoption-challenges-ai-trends.html)
-
-**Security & Vibe Coding:**
-- [Kaspersky: Vibe Coding Risks](https://www.kaspersky.com/blog/vibe-coding-2025-risks/54584/)
-- [Databricks: Dangers of Vibe Coding](https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding)
-- [Contrast Security: Vibe Coding Vulnerabilities](https://www.contrastsecurity.com/glossary/vibe-coding)
-
-**Technical Architecture:**
-- [VeritasChain: Cryptographic Audit Trails](https://veritaschain.org/blog/posts/2026-01-19-eu-ai-act-vcp-v1-1-cryptographic-audit-trails/)
-- [Sparkco: AI Audit Trail Requirements](https://sparkco.ai/blog/ai-model-audit-trail-documentation-requirements)