Build queue

Export packages for coding systems

Choose a capability, a specification version, and a builder adapter. The package contains the full spec plus builder-specific instructions.

# BUILD: Sovi Capability Foundry

You are implementing a capability for the Sovi personal AI operating environment.

Builder profile: **Grok Build**
Build scope: **maximum-viable**
Deployment target: **self-host / preview**
Constraints: Human-in-the-loop. Do not fake integrations.

## North star

Do not build a toy prompt wrapper. Build the foundations of a genuine system.

The durable asset is the structured capability specification below. You are an interchangeable implementation layer.

## Software form

Intelligence System

## Problem

Conversations and research remain inert; they are not converted into buildable software capabilities.

## Build now

- Corpus ingest with immutable originals
- Conversation analysis and asset extraction
- Capability review with overlap proposals
- Specification and Grok Build package generation
- Sovi manifest + self-registration

## Integrate later (interfaces only — do not fake)

- Sovi launcher registration bus
- External conversation export adapters
- Vector retrieval

For each integrate-later item, generate adapters, schemas, configuration, API contracts, placeholders, documentation, and validation criteria. Never pretend the integration is complete.

## Required repository documentation

- README.md
- SOVI-INTEGRATION.md
- SOVI-MANIFEST.yaml
- docs/architecture.md
- docs/capability-map.md
- docs/source-registry.md
- docs/ingestion-spec.md
- docs/api-contracts.md
- docs/agent-behavior.md
- docs/data-schema.md
- docs/completion-plan.md
- docs/verification-tests.md
- docs/provenance.md
- docs/security.md
- docs/deployment.md

Also generate a valid `SOVI-MANIFEST.yaml` describing identity, launch URL, health endpoint, APIs, tools, events, unfinished integrations, and human approval gates.

## Provenance

Preserve links from features back to specification sections. Do not discard source relationships.

## Acceptance

The result must be usable without reconstructing the original conversation. A future Sovi agent should be able to register the application from its manifest.

## Grok Build operating notes

This is a paste-ready Grok Build Master Prompt. Construct the maximum viable implementation that can run as a self-contained web application, with integrate-later seams clearly documented.

Use a professional interface. Prefer a real data model over mock screens.

---

# Sovi Capability Foundry — Capability Specification v1

## 1. Executive Summary

Sovi Capability Foundry is a Intelligence System that Transforms accumulated intellectual work into structured executable capabilities..

This specification is builder-agnostic. Grok Build, Codex, Claude Code, a human team, or Sovi itself may implement it. The durable asset is this document, not any one prompt.

## 2. Problem Definition

Conversations and research remain inert; they are not converted into buildable software capabilities.

## 3. Objectives

- Deliver a usable Intelligence System for the operator.
- Preserve provenance from corpus through requirements to software.
- Separate build-now work from integrate-later contracts.
- Expose a Sovi manifest and health endpoint.

## 4. Non-Objectives

- Do not fake unavailable Sovi, Drive, Git, or third-party integrations.
- Do not silently overwrite original corpus or generated specs.
- Do not autonomously deploy or register without approval gates.
- Do not reduce the capability to a chatbot wrapper if a structured system is required.

## 5. Intellectual Assets

- Conversation-to-Capability Master Protocol (Methodology)

## 6. Functional Requirements

1. Corpus ingest with immutable originals
2. Conversation analysis and asset extraction
3. Capability review with overlap proposals
4. Specification and Grok Build package generation
5. Sovi manifest + self-registration

## 7. Nonfunctional Requirements

- Self-hostable; no required telemetry.
- Operator-owned data with export and deletion.
- Documented API and schema.
- Accessible tablet/PWA layout.
- Expected complexity: L.

## 8. User Experience

Primary operator is a single owner running Sovi.

Core surfaces: overview, records, provenance, and an action to generate the next durable artifact (spec, build package, manifest).

Tablet usability matters. Dense but calm. No decorative chrome.

## 9. Architecture

TanStack Start application with Postgres, multi-pass analysis jobs, versioned specs, builder adapters, and a capability registry.

## 10. Data Architecture

Persist canonical records in Postgres.

Minimum entities: corpus, sources, assets, capabilities, specifications, manifests, registry entries, graph edges, activity.

Original corpus is immutable. Interpretations live in versioned artifacts.

## 11. Knowledge Architecture

Traceability chain:

Software feature → capability requirement → intellectual asset → conversation → source.

Search should be upgradeable to embeddings without replacing the relational model.

## 12. AI/Agent Architecture

Analysis is multi-pass. Failed stages resume.

Provider is abstracted. Store provider/model on generated artifacts.

Sovi may operate the Foundry through the HTTP API. Consequential writes stay behind approval gates.

## 13. API Architecture

Expose health, OpenAPI, corpus ingest, analysis, capabilities, specs, build packages, manifests, registry, and system map.

Do not require the UI to be the only client.

## 14. Integrations

xAI for analysis; Postgres; future Sovi launcher and event bus

## 15. Security

Self-hosted. Secrets via environment. No secrets in git.

Identify when corpus would leave the environment for an external model.

## 16. Privacy

Corpus may contain highly sensitive intellectual property. Default is operator-owned, exportable, and deletable.

## 17. Permissions

Human approval required for capability approval, spec approval, build start, deploy, register, permission changes, and destructive actions.

## 18. Deployment

Linux VPS or container. Postgres. Environment variables. Health endpoint. No Kubernetes required.

## 19. Portability

Postgres, Markdown, JSON, YAML, OpenAPI, containers. Avoid vendor lock-in.

## 20. Observability

Job status, stage, logs, activity feed, health endpoint.

## 21. Backup/Recovery

Database dump plus corpus export. Restore by migrating schema then importing JSON/Markdown.

## 22. Build-Now Requirements

## 23. Integrate-Later Requirements

1. Sovi launcher registration bus
2. External conversation export adapters
3. Vector retrieval

For each integrate-later item, ship:
- interface / adapter contract
- schema
- configuration keys
- validation criteria
- documentation

Never instruct a coding agent to pretend the integration is complete.

## 24. Risks

- Missing information: Usage-based value scoring still open.
- Duplicate capabilities if overlap review is skipped.
- Prompt-only artifacts if specifications are not versioned.
- Quota spend if analysis is run on huge corpora without clipping.

## 25. Research Gaps

- How to score capability value without a usage graph.

## 26. Acceptance Criteria

- Operator can ingest source material without losing the original.
- Extracted claims link back to source spans.
- Overlap with existing capabilities is presented, not auto-merged.
- A builder-agnostic spec can be generated and edited.
- A Grok Build package can be copied and exported.
- A valid SOVI-MANIFEST is produced.

## 27. Sovi Integration Requirements

Core Sovi subsystem. Registers itself and other applications.

## 28. Source Registry

- Conversation-to-Capability protocol

## 29. Provenance

Originating corpus:
- Sovi Capability Foundry founding specification

Capability cap_sovi_foundry (sovi-capability-foundry).

## 30. Version History

v1 — generated from capability Sovi Capability Foundry