Qubit Jarvis Documentation
## Purpose
This folder is the documentation source for Qubit Jarvis, the venture studio operating system used to build, operate, and improve revenue-generating systems.
## Current Status
Initial source structure created for architecture, business, builder, crypto, operations, and roadmap documentation.
## Key Notes
- Documentation should stay close to the operating reality of Qubit Jarvis.
- Business value, revenue impact, and operational clarity should guide future updates.
- API, Docker, Nginx, environment, and site files are intentionally out of scope for this documentation structure.
## Next Steps
- Fill each document with current implementation details.
- Link documents together as the source of truth matures.
- Add review cadence for keeping documentation current.
API
## Purpose
Document Qubit Jarvis API responsibilities, endpoint groups, request and response contracts, and integration boundaries.
## Current Status
Placeholder documentation created. API code was not modified.
## Key Notes
- API implementation details should be verified from source before documenting exact endpoints.
- Endpoint documentation should include method, path, request body, response shape, and failure modes.
- API docs should distinguish stable contracts from internal or experimental endpoints.
## Next Steps
- Inventory current FastAPI routes.
- Document authentication and authorization assumptions.
- Add endpoint examples after verification.
Infrastructure
## Purpose
Document the infrastructure that runs Qubit Jarvis, including host environment, containers, reverse proxy, runtime services, and operational dependencies.
## Current Status
Placeholder documentation created. Infrastructure details need to be expanded from verified deployment state.
## Key Notes
- Known infrastructure includes Ubuntu, Docker Compose, Nginx, FastAPI, Redis, and n8n.
- Infrastructure changes require explicit owner approval.
- Secrets, certificates, DNS, firewall rules, and environment files must not be modified without approval.
## Next Steps
- Inventory services and container names.
- Document network boundaries and public entry points.
- Add backup, restore, and deployment expectations.
Architecture Overview
## Purpose
Describe the high-level architecture of Qubit Jarvis and how its infrastructure, APIs, data stores, agents, and business systems fit together.
## Current Status
Placeholder documentation created. Detailed architecture content still needs to be captured from the running system.
## Key Notes
- Qubit Jarvis runs as a venture studio operating system.
- Current known components include Ubuntu, Docker Compose, Nginx, FastAPI, Redis, and n8n.
- Core systems include opportunity, product, revenue, and experiment workflows.
## Next Steps
- Document major services and their responsibilities.
- Add system context and component diagrams.
- Identify ownership boundaries between infrastructure, API, agents, and business workflows.
Redis Schema
## Purpose
Document Redis keys, data models, expiration policies, ownership, and operational risks for Qubit Jarvis.
## Current Status
Placeholder documentation created. Redis schema details need verification from code and runtime usage.
## Key Notes
- Redis keys should be documented with purpose, producer, consumer, and expected data shape.
- Expiration and retention behavior should be explicit.
- Data deletion or migration requires owner approval when production data may be affected.
## Next Steps
- Inventory Redis key prefixes from source.
- Document value formats and lifecycle rules.
- Add migration notes for any future schema changes.
AI App Factory
## Purpose
Document the AI App Factory business line, including offer, target customer, delivery model, revenue assumptions, and operating workflow.
## Current Status
Placeholder documentation created. Existing deployment notes indicate a static AI App Factory landing page has been deployed.
## Key Notes
- AI App Factory should be documented as a revenue-generating productized service.
- Documentation should connect the public offer to internal delivery, proposal, and build workflows.
- Revenue evidence should be tracked separately from assumptions.
## Next Steps
- Capture offer positioning, pricing, and target customer profile.
- Document lead intake and fulfillment workflow.
- Link deployment and operational notes from the operations docs.
CRM Pipeline
## Purpose
Document how Qubit Jarvis tracks leads, prospects, opportunities, customers, and revenue movement through the business pipeline.
## Current Status
Placeholder documentation created. CRM pipeline implementation details need to be captured.
## Key Notes
- Pipeline stages should reflect actual selling and delivery behavior.
- Customer, opportunity, and revenue records should have clear ownership.
- Automation should reduce manual follow-up while preserving evidence.
## Next Steps
- Define pipeline stages and required fields.
- Document lead sources and qualification rules.
- Add reporting needs for revenue forecasting.
Proposal Engine
## Purpose
Document the system for generating, tracking, and improving business proposals for Qubit Jarvis opportunities.
## Current Status
Placeholder documentation created. Proposal generation workflows need to be documented from current practice.
## Key Notes
- Proposals should be tied to specific customer problems, scope, pricing, and expected revenue.
- Generated content should remain reviewable before customer delivery.
- Proposal outcomes should feed back into business learning.
## Next Steps
- Define proposal inputs, templates, and approval steps.
- Document pricing and scope assumptions.
- Track proposal status and win or loss reasons.
Revenue Engine
## Purpose
Document how Qubit Jarvis identifies, tracks, validates, and grows revenue across products, services, and experiments.
## Current Status
Placeholder documentation created. Revenue engine details need to be expanded.
## Key Notes
- Revenue beats novelty in Qubit Jarvis decision-making.
- Business documentation should separate confirmed revenue from hypotheses.
- Revenue systems should connect opportunities, proposals, delivery, invoices, and follow-up.
## Next Steps
- Define revenue metrics and reporting cadence.
- Document active revenue streams and target segments.
- Add links to CRM, proposal, and product delivery workflows.
Codex Execution
## Purpose
Document how Codex should execute work inside Qubit Jarvis, including constraints, validation expectations, and handoff format.
## Current Status
Placeholder documentation created using repository constitution guidance. No code changes were made.
## Key Notes
- Codex must not commit unless explicitly instructed by Dc.
- Codex must avoid modifying API, Docker, Nginx, environment, or site files unless the task explicitly authorizes it.
- Validation, git status, and clear change summaries are required before stopping.
## Next Steps
- Capture standard execution checklists for common task types.
- Add examples for documentation-only, API, infrastructure, and deployment tasks.
- Link this document to repository-level operating rules.
Builder Projects
## Purpose
Document active and historical build projects managed by Qubit Jarvis, including business rationale, scope, status, and delivery outcomes.
## Current Status
Placeholder documentation created. Project inventory needs to be added.
## Key Notes
- Projects should connect technical work to business value.
- Project status should be clear enough to support prioritization.
- Completed projects should capture outcomes and reusable lessons.
## Next Steps
- Inventory active projects.
- Define project status categories.
- Link project records to specifications, tasks, and deployment notes.
Builder Specifications
## Purpose
Document product and technical specifications used by the Qubit Jarvis builder workflow.
## Current Status
Placeholder documentation created. Specification format and current specs need to be added.
## Key Notes
- Specifications should be small, testable, and tied to outcomes.
- Requirements should distinguish business goals from implementation details.
- Specs should define validation before build work begins.
## Next Steps
- Define a standard specification template.
- Add current product and feature specifications.
- Link specifications to implementation tasks and validation results.
Builder Tasks
## Purpose
Document how Qubit Jarvis tracks builder tasks, execution state, validation, and completion criteria.
## Current Status
Placeholder documentation created. Task tracking conventions need to be documented.
## Key Notes
- Tasks should be narrow, reversible, and testable.
- Completion should include validation evidence.
- Task records should preserve decisions and constraints that affect implementation.
## Next Steps
- Define task states and required fields.
- Document task intake and prioritization flow.
- Link tasks to projects, specifications, and Codex execution records.
PnL Engine
## Purpose
Document crypto profit and loss tracking, including realized PnL, unrealized PnL, cost basis, and reporting behavior.
## Current Status
Placeholder documentation created. PnL implementation details need verification.
## Key Notes
- PnL calculations should be auditable.
- Cost basis rules must be explicit.
- Trading, deletion, or mutation of production financial data requires owner approval.
## Next Steps
- Document PnL formulas and data dependencies.
- Add example calculations.
- Define reconciliation and reporting cadence.
Portfolio Engine
## Purpose
Document the crypto portfolio engine, including portfolio tracking, asset allocation, valuation inputs, and risk controls.
## Current Status
Placeholder documentation created. Crypto implementation details need verification before expansion.
## Key Notes
- Codex must not execute trades.
- Crypto trading requires explicit owner approval.
- Portfolio documentation should separate observation, valuation, and action.
## Next Steps
- Inventory current portfolio data sources and models.
- Document allocation and risk assumptions.
- Add owner approval flow for any trading-related workflow.
Valuation V2
## Purpose
Document the second version of crypto valuation logic, including inputs, methodology, assumptions, and output format.
## Current Status
Placeholder documentation created. Valuation V2 details need to be captured from source or design notes.
## Key Notes
- Valuation logic should make assumptions explicit.
- Market data freshness and source reliability should be documented.
- Outputs should distinguish estimates from verified balances or realized profit and loss.
## Next Steps
- Define valuation inputs and calculation flow.
- Document supported assets and data providers.
- Add validation cases for valuation output.
Deployment Log
## Purpose
Track production and public deployment events for Qubit Jarvis, including dates, scope, URLs, source paths, infrastructure touched, and verification results.
## Current Status
Existing deployment log content moved from docs/deployment-log.md into this operations document.
## Key Notes
- Deployment entries should be factual and date-stamped.
- Public URLs, source paths, and verification status should be recorded.
- Production deployments require owner approval.
## Existing Entries
### 2026-06-22 - AI App Factory Deployment
Deployed static AI App Factory landing page.
Public URL:
https://appfactory.qubit.co.bw
Source path:
sites/ai-app-factory
Nginx site:
appfactory.qubit.co.bw
Status:
- HTTP redirects to HTTPS
- HTTPS returns 200 OK
## Next Steps
- Add owner approval references for future deployments.
- Record validation commands and outputs for each deployment.
- Link deployments to business and builder documentation.
Incident Log
## Purpose
Track operational incidents, outages, degraded behavior, root causes, remediation, and follow-up work for Qubit Jarvis.
## Current Status
Placeholder documentation created. No incidents were added as part of this task.
## Key Notes
- Incident records should include date, impact, detection, response, resolution, and prevention.
- Action items should be linked to builder tasks or roadmap items.
- Sensitive operational details should not expose secrets.
## Next Steps
- Define incident entry format.
- Backfill known incidents if appropriate.
- Add review cadence for unresolved follow-up items.
Runbook
## Purpose
Document operational procedures for running, checking, recovering, and safely changing Qubit Jarvis.
## Current Status
Placeholder documentation created. Operational commands and procedures need to be captured and verified.
## Key Notes
- Runbook instructions should avoid exposing secrets.
- Destructive actions, production data deletion, firewall changes, DNS changes, and certificate changes require owner approval.
- Procedures should include expected outputs and rollback notes where possible.
## Next Steps
- Document health checks and service inspection commands.
- Add deployment and rollback procedures.
- Add incident response steps and escalation rules.
Current Roadmap
## Purpose
Document the current roadmap for Qubit Jarvis, including near-term priorities, business goals, technical work, and validation milestones.
## Current Status
Placeholder documentation created. Roadmap content needs owner-reviewed prioritization.
## Key Notes
- Roadmap items should be tied to revenue, evidence, automation, or infrastructure reliability.
- Near-term work should favor small working systems.
- Roadmap changes should preserve clear rationale.
## Next Steps
- Add current quarterly and monthly priorities.
- Separate committed work from candidate ideas.
- Link roadmap items to business systems and builder projects.
Self-Improving Jarvis
## Purpose
Document the roadmap and operating model for making Qubit Jarvis improve its own systems, documentation, workflows, and business outcomes over time.
## Current Status
Placeholder documentation created. Self-improvement loops need to be defined.
## Key Notes
- Self-improvement should prioritize measurable business and operational value.
- Automation should reduce repeated manual work.
- Changes must remain small, testable, and reversible.
## Next Steps
- Define feedback loops from incidents, deployments, revenue, and experiments.
- Identify safe automation candidates.
- Add metrics for measuring improvement over time.