- Network access to the 6 source APIs/feeds (arxiv, github, huggingface, hackernews, reddit, rss_feeds)
-`GITHUB_TOKEN` available as an environment variable (optional, but raises the GitHub rate limit from 60/hr to 5000/hr)
-`HUGGINGFACE_TOKEN` available as an environment variable
- A local Ollama instance running `llama3.2:1b`, or an alternate reachable inference backend if swapping — per the model-agnostic `summarize(text) -> (summary, model)` contract
- Hermes cron infrastructure available and able to invoke `oracle-pipeline.sh`
## Setup
1. Clone `main` (not a milestone branch) onto the target host
2.`pip install -r requirements.txt` if present; otherwise confirm stdlib + `requests` are available
3. Run `schema.sql` against a fresh `oracle.db` — this file is git-ignored and created locally, never committed
4. Export required environment variables (`GITHUB_TOKEN`, `HUGGINGFACE_TOKEN`) — never hardcode these
5. Build and run inside Docker with the 150MB memory cap and non-root user enforced, per the PRD platform requirements
6. Manual smoke test: run `python3 pipeline.py` once and confirm ingest → store → summarize → score completes without errors before handing off to cron
## Cron / Scheduling
1. Confirm `oracle-pipeline.sh` is the entry point Hermes cron calls
2. Schedule for 13:00 UTC daily
3. Add a lock file or PID check so overlapping runs can't happen if a prior run is still in progress
4. Confirm the cron environment actually carries the exported tokens — cron environments are frequently minimal and won't inherit an interactive shell's exports
## Hermes Integration
1. Confirm the wrapper script's exit codes are meaningful (0 = success, non-zero = failure) so Hermes can act on them
2. Define where Hermes should look for pipeline output/logs
3. Decide on a failure-notification path (Hermes alert, log flag, etc.) — **not yet specified, needs a decision**
## Monitoring
1. Aggregate logs from each pipeline stage (ingest, store, summarize, score)
2. Track theme-scan new-arrival counts per cycle per theme — this is the core signal the falsification logic depends on, so it deserves visibility beyond raw logs
3. Add a heartbeat/dead-man's-switch alert if a scheduled run doesn't fire, rather than relying on someone noticing missing data days later
4. Watch memory usage against the 150MB cap under real production load, not just dev conditions
## Rollback
1. Back up `oracle.db` before any schema change — it's git-ignored and not recoverable from the repo itself
2. If a bad deploy breaks the pipeline, revert to the last known-good commit on `main` and redeploy the Docker image
3. Check falsification state (new-arrivals counters) after any rollback — rolling back mid-window could distort the 7-day dead-thesis calculation if not handled carefully
---
*Draft prepared by Claude from the README, whitepaper falsification logic, and MVP-PRD platform requirements on `main`. The Hermes failure-notification path is the one open decision blocking this from being final.*
> *Surfacing cross-source convergence and using falsification to distinguish real momentum from noise.*
Athena is an autonomous research intelligence engine that ingests from multiple fragmented sources, detects when the same signals appear across independent channels, and uses decay-based falsification to separate genuine trends from one-day spikes. The system is model-agnostic, lightweight, and designed to run unattended on a resource-constrained VPS.
### How this design supports the north star
| North Star Principle | Design Decision | Why |
|---|---|---|
| Cross-source convergence | Keyword co-occurrence matrix (Phase 1), embeddings + vector search (Phase 2) | Keyword co-occurrence is the simplest convergence detector: if the same entity appears in ≥3 independent sources within a time window, it's converging. Embeddings Phase 2 adds semantic convergence for signals that use different words but mean the same thing. |
| Falsification over confirmation | Exponential decay scoring | A 7-day hard cutoff is blunt: some trends die in 48 hours, some take 60 days to validate. `score = base_score * e^(-λ * days_since_last_signal)` naturally scores dying trends low and sustained trends high without arbitrary day thresholds. |
| Autonomous operation | Cron/scheduled pipeline + graceful degradation | The pipeline runs daily without human intervention. If Ollama is down, ingestion continues and summarization defers to the next run. If one adapter fails, the rest still run. |
| Lightweight deployment | Python + SQLite + Flask + host-level Ollama | No PostgreSQL, no Elasticsearch, no Redis, no Kubernetes. A single Python process, a single SQLite file, and an external Ollama REST API. |
### MVP Success Criteria
The MVP is considered successful when:
1.**Research Time**: Bob answers 'what's trending this week' in <15 min of research time total (across all sources).
2.**Signal Detection**: Over 7 days, the theme scan correctly identifies ≥1 real trend that has genuine cross-source convergence.
3.**Noise Rejection**: Over the same 7-day period, the falsification engine kills ≥1 false signal (a one-day spike with no sustained arrivals) to demonstrate decay-based filtering is working.
| Hacker News | Firebase API | Unofficial, ~30 req/sec | No |
| HuggingFace | REST API | Throttled if aggressive | `HUGGINGFACE_TOKEN` |
| RSS Feeds | RSS XML | Varies | No |
**Decision:** HTTP-only adapters, no Playwright/Selenium. All 6 sources have programmatic APIs. Playwright would add Chromium's 300MB+ overhead and fragility.
### 4.2 Deduplication
arXiv papers appear on HN, Reddit, and Twitter. Without deduplication, the same signal is counted 3× and produces false convergence.
- **Phase 1:** UNIQUE constraint on `(source, source_id)` + URL hash dedup across sources
- **Phase 2:** SimHash/MinHash content fingerprinting for near-duplicate detection
### 4.3 Rate limiting and retries
- Per-adapter rate limits enforced in the adapter class
- `tenacity` library for exponential backoff on transient failures (429, 503, timeout)
- One failing adapter does not kill the pipeline
### 4.4 Adapter Interface Contract
All adapters must implement this minimal interface:
- **name() → str**: Unique identifier for the source (e.g., `"arxiv"`)
- `source_id` (str): Unique per-source ID for deduplication
- `title` (str): Human-readable title
- `url` (str): Direct URL to the entry
- `timestamp` (datetime): Publication/update time
- `raw_score` (float): Source-specific signal strength (0.0–10.0)
- `body` (str): Raw text content for summarization and theme tagging
**Custom Exceptions:**
- `RateLimitError`: Raised when source returns 429 or similar; includes `retry_after` (seconds)
- `SourceUnavailableError`: Raised when source is down (5xx) or unreachable
Adapters must not raise other exceptions on normal operation; unexpected errors should be logged with full traceback and surfaced via the run_log, not propagated to the pipeline.
---
## 5. Theme Tagging and Convergence Detection
### 5.1 Phase 1: Keyword co-occurrence
Pre-defined keyword dictionaries per theme. An entry is tagged if ≥2 keywords from a theme dictionary appear in its title or extracted text. A theme "converges" if it appears in ≥3 independent sources within the last 24 hours.
**Why keyword first at 150MB:** Keyword matching is zero-dependency, explainable, and works within the memory constraint. FTS5 provides fast retrieval.
**Fixed themes:** The initial 4 themes (`tool-call`, `context`, `compute`, `trust`) are seeds, not a hard limit. An "other" catch-all bucket captures signals that don't match predefined themes.
### 5.2 Phase 2: Embeddings + auto-discovery
- **all-MiniLM-L6-v2** (22M params, ~80MB) for sentence embeddings
- **sqlite-vec** for in-database ANN search
- **BERTopic** (or equivalent) for semi-supervised theme discovery, seeded from the Phase 1 dictionary
- Hybrid query: FTS5 for precision (keyword match) + vector for recall (semantic match), merged via Reciprocal Rank Fusion
**Why not keyword forever:** Keyword matching cannot detect semantic convergence (different words, same concept) and requires constant manual dictionary updates. Embeddings are the eventual target; Phase 1 is the bridge.
- `keywords`: list of keyword patterns for Phase 1 regex matching
- `owner`: responsible person (for quarterly review)
- `created_at`: ISO date of creation
- `status`: `active` or `deprecated`
**Lifecycle:**
- **Propose**: New themes require owner nomination + approval from project lead
- **Review**: Active themes are reviewed quarterly; deprecated if <2 hits in 30 days
- **Retire**: Deprecated themes are excluded from convergence scoring after 90 days
- **Reinstate**: Deprecated themes can be reactivated if signals re-emerge
The "other" catch-all bucket captures signals that don't match any active theme and is reviewed during quarterly theme audits for potential new theme creation.
- Better logging than cron (`journalctl -u athena-timer`)
### 9.3 Why not APScheduler (Phase 1)
APScheduler adds in-process async daemon overhead. Cron/systemd is OS-level, zero process memory cost, and sufficient for daily runs. APScheduler is the Phase 2 target if dynamic scheduling (user-configurable refresh rates, per-source intervals) is needed.
### 9.4 Scheduling Recommendation
- **Phase 1 (MVP)**: Use system cron for daily runs at 13:00 UTC. Sufficient for fixed schedule, zero process memory cost, OS-level reliability.
- **Phase 2**: Switch to systemd timers if dynamic scheduling needed (skip runs on holidays, adjust time zones). Better observability and integration with monitoring tools.
- **APScheduler**: Only use if per-source intervals are required (e.g., arXiv every 6 hours, Reddit every 30 min). Adds ~50MB process overhead — not recommended for Phase 1.
**Recommendation**: Start with cron for Phase 1. Evaluate whether Phase 2 sources need different intervals before considering systemd timers or APScheduler.
---
## 10. Inference
### 10.1 Summarization
**Model:** Ollama `llama3.2:1b` (or `qwen2.5:0.5b` for lower resource)
**Deployment:** Host-level Ollama service, pipeline calls via HTTP REST API
**Graceful degradation:** If Ollama is down, store raw text and defer summarization
### 10.2 Why not in-container Ollama
Ollama daemon + 1B model requires ~2GB RAM. Running it inside the 150MB container is physically impossible. Running it host-level means the pipeline process stays within budget and Ollama can share resources with other services.
### 10.3 Model Upgrade Process
- **Swap model**: Replace model file; update systemd unit `ExecStart` path if needed
- **Quality check**: Run first summarization on known-good source (e.g., arXiv paper), compare output against baseline summary for content accuracy, length consistency, and hallucination rate
- **Rollback**: If quality degrades (e.g., summary length <50 tokens, hallucination rate >10%), revert to previous model file immediately
**Quality metrics**: Pass if summary is >50 tokens, no hallucinations on known entities, and theme detection matches golden samples. Only proceed with upgrade after successful verification.
---
## 11. Security
| Requirement | Implementation |
|---|---|
| No hardcoded secrets | `GITHUB_TOKEN`, `HUGGINGFACE_TOKEN` as env vars or mounted secret files |
| TLS for outbound | All HTTP adapters use `https://` |
| Least privilege | Pipeline runs as standard user (no sudo) |
| REQ-SCH-20 | Overlapping run prevention via flock or PID file check |
---
## 14. Design Decisions Summary (Why)
| Decision | Why | Revisit |
|---|---|---|
| **SQLite over PostgreSQL** | Zero external dependency, single file, FTS5 built-in, handles 1M rows fine. pgvector is premature at this scale. | P6 (if scale demands pgvector) |
| **Ollama host-level** | 150MB container cannot fit Ollama + model (~2GB). Host-level lets pipeline stay within budget. | P2 (if inference needs change) |
| **Flask over FastAPI** | ~1MB vs ~100MB runtime overhead. FastAPI is Phase 2 target; Flask suffices for internal REST API. | P2 (when FastAPI becomes viable) |
5. Check GPU: `nvidia-smi` — ensure service actually loaded
**Escalation**: If issue persists after restart, notify project lead.
**Runbook maintenance**: Update runbooks when features change. Document changes in `runbook_changes.md`.
## 18. Risk Register and Assumptions
### 18.1 Risk Register
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Source API changes (rate limits, endpoint shifts) | High | High | Auto-retry with exponential backoff; monitor adapter health; log API changes for review |
| Model quality drift (summarization accuracy degrades) | Medium | Medium | Weekly golden sample comparison; rollback if hallucination rate >10% or summary <50 tokens |
| Disk space exhaustion (backups, logs) | High | High | Automated 30-day retention; alert at 85% usage; compress old backups |
| Single operator bottleneck (manual theme review) | Medium | Medium | Documented theme governance; quarterly review cycle; catch-all "other" bucket |
| Network outage (all adapters fail) | Low | High | Graceful degradation: store raw data without summaries; resume when network returns |
| SQLite corruption during schema migration | Low | Critical | Pre-migration backup; atomic migration scripts; integrity check after each migration |
### 18.2 Key Assumptions
- All 6 source APIs remain stable for at least 6 months (no breaking changes)
- GPU memory available for Qwythos inference (~15GB free on GPU0)
- Network connectivity to all sources is available during pipeline runs
- Single operator can complete manual theme review within 24 hours
- Disk space sufficient for 30-day backup retention (~10GB)
**Risk review**: Quarterly review of this register; update mitigations when new risks emerge.
**Assumption tracking**: If an assumption proves false, document the deviation in `assumption_deviations.md` and reassess risks.
## 19. Dependencies and Tooling
### 19.1 Python Runtime Dependencies
All dependencies pinned to exact versions in `requirements.txt`:
- Critical security updates: Apply within 7 days of CVE disclosure
- Minor version updates: Test in staging before production deployment
- Major version upgrades: Require migration scripts and rollback plan
**Tooling policy**: No new dependencies without approval from project lead; document rationale in `dependency_justifications.md`.
**Lock file**: `requirements.txt` pinned to exact versions for reproducible builds.
---
*Document prepared via multi-model analysis: Qwythos-9B (architectural critique), Qwen3.5-9B (implementation evaluation), and cross-review synthesis. 4 delegations, 2 rounds of debate. Raw reviews saved in the same directory.*
Athena is an autonomous research intelligence engine that cuts through high-volume, fragmented signals by ingesting from multiple sources, surfacing cross-source convergence, and using falsification to distinguish real momentum from noise. While the initial focus is on AI signals, the system is designed to work with any class of signals. It delivers actionable insight into emerging trends and capability gaps while remaining model-agnostic and lightweight enough to run autonomously.
### 1.1 Vision
#### Why are we building it?
The AI space produces an overwhelming volume of new research, tools, discussions, and model releases every day. Individual sources only provide partial views, making it difficult to distinguish genuine, sustained trends from one-day spikes. Without a system that can detect convergence across sources and validate momentum over time, real opportunities tied to emerging capability gaps are missed.
#### What happens if we don’t build it?
Without this capability, builders and researchers will continue to operate with fragmented, noisy signals. Early indicators of meaningful trends will remain hidden, decisions will stay reactive, and the ability to spot validated cross-source momentum before it becomes obvious will be lost.
#### When must it be done?
The foundational ability to reliably ingest, score, and validate signals through falsification must be established before meaningful trend detection and opportunity mapping can occur. This forms the core of the MVP and must be in place to enable the system to deliver on its intended value.
### 1.2 Personas and Archetypes
See committed document:
**`docs/Personas-and-Archetypes.md`** (on `MVP-milestone` branch)
**Summary of scoped personas and archetypes for MVP:**
**Personas**
- Pers-1 (Bob) – Sector Trend Tracker (New to AI)
- Pers-2 (Alice) – Content Creator
- Pers-3 (Sam) – Hermes Research Agent
**Archetypes**
- Arch-1 (Small Scrappy VPS)
- Arch-2 (Research Consumption Layer)
All user stories in this PRD are scoped to combinations of the above.
### 1.3 Use Case Priority Taxonomy
This PRD focuses on defining the core functionality required for MVP. It also catalogs use cases and requirements across V1.0 – V1.5 to maintain context. The primary goal is to deliver a working MVP, with future PRDs derived from the remaining prioritized content.
We will use the following prioritization model:
- **MVP**: The short list of P1 use cases required to prove the concept with a working prototype.
- **P1**: Use cases that are fundamental to successfully implementing the product vision.
- **P2**: Use cases that add strength, convenience, and quality to the product vision.
- **P3**: Use cases that bring additional value but can be cut if time or resource constrained.
## Chapter 2: User Stories (Bob)
These user stories are based on the personas and archetypes document contained in this repo.
Chapter 2.1 - Bob's user stories
**As Bob, I want to…**
**Bob-1.** Automatically receive daily updates on new AI innovations without having to manually check multiple sources.
**Bob-5.** See emerging trends and differentiate durable signal from temporary or artificial hype.
**Bob-10.** See when the same idea or pattern is appearing across multiple independent sources (GitHub, arXiv, Reddit, HN, HF).
**Bob-15.** Identify emerging capability gaps or opportunities early, before they become widely obvious.
**Bob-20.** Have research that gives me confidence it is exhaustive and vetted.
**Bob-25.** Adjust or alter the underlying data feeds and weights so I can tune the accuracy and relevance of the output.
**Bob-30.** Understand why a particular signal is considered strong or weak (e.g., cross-source convergence or falsification results).
Chapter 2.2 - Alice's user stories
As Alice, I want to…
Alice-1. Integrate deep, vetted research directly into my existing content production pipeline so I can reduce manual research time.
Alice-5. Query the research system with follow-up questions to explore specific angles or topics on demand.
Alice-10. Have my tools automatically receive curated, high-signal research so I can focus on content creation instead of information filtering.
Alice-15. Get research outputs in a structured format that my existing AI tools and workflows can consume without manual reformatting.
Alice-20. Quickly surface non-obvious insights and patterns from research data to develop more compelling content angles.
Alice-25. Control which research sources and signals are prioritized so the output stays aligned with my content focus and audience.
Alice-30. Understand the reasoning and supporting evidence behind key research findings so I can speak to them confidently in my content.
## Chapter 3: Requirements
Requirements defined as what the product / system must do, differentiated from what the persona can accomplish. Requirements are defined to meet the needs of use cases as well as the architectural system design.
High level design (refer to ***TBD_Design.MD for full design details)
High-Level Design
.
├── Runtime Environment
│ ├── Linux
│ └── Docker (containerized)
│
├── Core Components
│ ├── Database: SQLite
│ ├── Scheduling: Cron
│ └── Runtime: Python
│
├── Connectivity
│ ├── Outbound (Internet)
│ │ ├── HTTP client for data feeds (RSS, cURL, optional Playwright)
│ │ └── OpenAI-compatible inference endpoints
│ ├── Inbound (Internet)
│ │ └── HTTP server endpoint (MCP + external consumers)
│ └── Internal (Intranet)
│ └── HTTP client for local inference (e.g. Hermes)
│
├── Storage
│ ├── File system (daily digest artifacts stored outside container)
│ └── Temporary working storage during pipeline execution
│
├── Configuration & Secrets
│ ├── Research topic manifest (feeds, URLs, declarations)
│ ├── System settings (YAML)
│ └── Secrets (.env)
│
├── Business Logic / Pipeline Flow
│ ├── Starting trigger
│ ├── Preflight checks
│ ├── Query feeds → Temporary result storage
│ ├── Vet and promote final results to database
│ ├── Optional daily digest generation
│ └── Cleanup and sleep
│
└── Observability
├── Structured logging
├── Diagnostics and instrumentation (inside Docker)
└── Health/status reporting
3.1 Setup and configuration (REQ-SNC-XX)
Requirements for initial setup, deployment configs, updating, and uninstall
REQ-SNC-05 -, with outbound access to the internet and in/outbound access to the underlying OS network
REQ-SNC-10 - The installation process shall be a single command which can be run interactively or silently
REQ-SNC-15 - The insallation shall utilize best-practice settings and secrets storage
REQ-SNC-20 -
3.2 Platform requirements (REQ-PLT-XX)
REQ-PLT-05 - All processes will run as standard user (no admin / sudo elevation necessary)
REQ-PLT-10 - ...
REQ-PLT-15 - The system shall be Docker based limited to 150MB of memory
Requirements addressing what OS and hardware support is in scope
3.3 Performance and scalability (REQ-PERF-XX)
3.4 Instrumenation and diagnostics (REQ-DIAG-XX)
3.5
### 3.1 Reliability
REQ-REL-05: Once setup and configured, the system will reliably operate without interaction from the user.
REQ-REL-10: The system shall automatically retry failed source fetches with exponential backoff.
REQ-REL-15: The system shall not lose previously stored data on restart or failure.
REQ-REL-20: The daily pipeline shall complete successfully even if one or more sources are unavailable.
3.3 Observability and Diagnostics
REQ-DIAG-05: The system shall produce structured logs with timestamps and severity levels.
REQ-DIAG-10: A health check endpoint or command shall report overall system status and last successful run.
REQ-DIAG-15: Run logs shall capture per-source success/failure and basic metrics (items fetched, stored, failed).
3.4 Security
REQ-SEC-05: All external HTTP calls shall use TLS.
REQ-SEC-10: No secrets shall be hardcoded or stored in plaintext.
REQ-SEC-15: The system shall support least-privilege access for outbound API calls.
3.5 Integration and extensibility
REQ-INT-05: The system shall expose research output in a structured, machine-readable format (e.g., JSON files or API) consumable by external tools.
REQ-INT-10: The adapter layer shall support adding new sources without modifying core pipeline logic.
This document extracts the implied users and operating contexts directly from the current documentation on the `main` branch. It serves as the baseline before we expand or refine.
---
## Personas
### Pers-1 (Bob) – Sector Trend Tracker (New to AI)
- Is relatively new to AI and the broader space.
- Wants to stay current with trends in AI (and potentially other sectors) without getting overwhelmed.
- Needs a way to keep up with the high volume of new research, tools, and discussions with minimal ongoing effort.
- Benefits from a system that filters noise and surfaces what actually matters.
### Pers-2 (Alice) – Content Creator
- Runs a YouTube channel and an X account with 25k followers.
- Goal is to grow her audience significantly (targeting 1M followers).
- Needs help doing research across AI and related topics.
- Wants to convert research signals into interesting, timely, and compelling content for her audience.
### Pers-3 (Sam) – Hermes Research Agent
- Is a Hermes agent profile with its own memory and endpoint connection.
- Acts as the dedicated research team member for an AI-first development team.
- Needs to stay current on a defined market segment (AI for the MVP; extensible to other segments later).
- Consumes structured signals from Athena to support ongoing research and decision-making within the team.
---
## Archetypes (Operating Environments)
### Arch-1 (Small Scrappy VPS)
- Small, low-budget, and scrappy VPS environment.
- Used primarily for learning and early prototyping.
- Requires a small-footprint workload that can be memory-constrained so it doesn’t destabilize the host system.
### Arch-2 (Research Consumption Layer)
- Functions as a consumption layer for Athena’s research output.
- Designed to support downstream AI systems (examples: MCP tools, LoRA adapters, or other agent profiles).
- Focuses on making Athena’s signals and summaries easily consumable by other systems rather than direct human use.
---
## Notes & Limitations (from /main)
- The current documentation does **not** describe team or multi-user usage.
- Emphasis is on autonomous operation and signal integrity.
- Polished human-facing interfaces (e.g., daily digest) are not yet built.
---
## Next Steps
This version incorporates the updated personas and archetypes.
Tied to the personas and requirements in `MVP-PRD.md`. Ordered by phase; within each phase, roughly in the order they should be tackled.
## Phase 1: Get Running Daily
- [ ] Verify the cron entry (`oracle-pipeline.sh`) fires reliably at 13:00 UTC under Hermes
- [ ] Confirm `pipeline.py` runs the full ingest → store → summarize → score cycle without manual intervention
- [ ] Add a lock/guard so a slow run can't overlap with the next day's cron trigger
- [ ] Validate all 6 adapters (arxiv, github, huggingface, hackernews, reddit, rss_feeds) independently — one adapter failing shouldn't kill the whole run
- [ ] Confirm environment-only secrets (`GITHUB_TOKEN`, `HUGGINGFACE_TOKEN`) resolve correctly in the cron context (cron environments are often stripped down compared to an interactive shell)
## Phase 2: Core Functionality
- [ ] Confirm `schema.sql` initializes `oracle.db` cleanly and stays idempotent across repeated runs
- [ ] Verify `theme_scan.py`'s 4-theme tagging (tool-call, context, compute, trust) against a few real days of data
- [ ] Confirm the falsification counter (new arrivals per cycle) is genuinely idempotent — re-running against unchanged data must yield 0 new
- [ ] Wire `summarize.py` to degrade gracefully when the Ollama endpoint (`llama3.2:1b`) isn't reachable — ingestion, scoring, and theme-scan must keep running without it
- [ ] Confirm `archive.py`'s cold-storage rotation doesn't delete data still needed inside the 7-day falsification window
## Phase 3: Observability & Reliability
- [ ] Add structured logging per pipeline stage (ingest, store, summarize, score) with pass/fail per adapter
- [ ] Surface theme-scan counts (new arrivals per theme per cycle) somewhere inspectable, not just buried in log files
- [ ] Add a daily heartbeat/health check so a silent failure (e.g. cron didn't fire at all) is detectable rather than just showing up as missing data later
- [ ] Decide and implement retry/backoff behavior for adapters that hit rate limits (especially GitHub without a token: 60/hr)
## Phase 4: Human Consumption Layer
- [ ] Extend `query.py` to support Bob's cross-source convergence lookups and Alice's curated-research pulls
- [ ] Define the output format(s) for a "trend confirmed" vs. "trend killed" verdict (per the 7-day dead-thesis rule)
- [ ] Decide how Alice's content pipeline actually consumes Athena's output — file drop, API, direct DB read — this is currently undefined
## Phase 5: Validation & UAT
- [ ] Run the pipeline unattended for at least one full 7-day falsification window
- [ ] Manually verify at least one theme through to a real "confirmed" or "killed" verdict
- [ ] Walk Bob's and Alice's user stories from `MVP-PRD.md` end-to-end against real output, not synthetic data
- [ ] Confirm memory stays under the 150MB cap under real daily load, not just in a light dev test
- [ ] Decide how Hermes is notified on pipeline failure vs. success — not yet specified
- [ ] Confirm the non-root execution requirement is actually satisfied inside the Hermes-invoked environment, not just in local Docker testing
---
*Draft prepared by Claude from the MVP-PRD, Personas doc, and README/whitepaper on `main`. Open items flagged "not yet specified" need a decision before Phase 4–6 can be considered done.*
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Ty
ty
Leonard