Project-Thoth/Revised Project Plan.md

Yes. The plan is directionally sound, but there are several gaps I would close before we begin rewriting architecture. Most of them arise because Project Thoth has evolved considerably beyond what the current .thoth documents describe.

The existing material gives us a strong foundation. It already establishes preservation, modularity, platform independence, deterministic processing, Markdown canonicality, self-description, ADRs, work orders, specifications, and the distinction between methodology and implementation. The problem is that the existing architecture and roadmap still describe the earlier capture-first Project Thoth rather than the complete application you now intend to build.

I would therefore make the current project an explicit re-foundation of Project Thoth, rather than incrementally editing the old plan.

1. Add a Project Reconciliation phase before SDLC design

Your first activity should not actually be "Select an SDLC methodology."

It should be:

Establish the authoritative state of Project Thoth.

Right now there are multiple generations of Project Thoth documentation.

For example, ADR-001 correctly establishes Project Thoth as a platform whose methodology is authoritative over any particular software implementation. That remains highly compatible with what you just described.

But the current architecture describes a primarily linear knowledge-preservation system:

External Sources → Capture → Archive → Processing → Repository → Search → AI Consumers.

That is no longer sufficient. The new application must also provide an interactive AI operating environment in which a user can choose Oracle/Ollama or a frontier provider, apply the Thinking Methodology, retrieve knowledge, continue a task across engines, and produce artifacts.

Likewise, 00-project-state.md still says the project is at version 0.0.1 and focused on the ChatGPT Capture Connector.

So add:

Phase 0 — Project Reconciliation

• Inventory all .thoth documents.

• Inventory specifications.

• Inventory ADRs.

• Inventory existing application/source code.

• Inventory previous experiments and abandoned implementations.

• Classify each artifact as:

  • Current
  • Requires Revision
  • Superseded
  • Historical
  • Candidate for removal

• Explicitly review every accepted ADR.

• Preserve valid decisions rather than silently rewriting history.

• Create superseding ADRs where architectural decisions have changed.

• Update 00-project-state.md only after this audit.

This prevents an AI developer three months from now from encountering two equally "canonical" descriptions of Project Thoth.

---

2. Separate the Project Thoth product from the Project Thoth application

You have effectively defined a product line:

Project Thoth
│
├── Methodology
│   ├── Knowledge Architecture
│   ├── Archiving Methodology
│   └── Thinking Methodology
│
├── Intellectual Property
│   ├── Project Thoth Book
│   ├── Consulting Methodology
│   └── Specifications
│
├── Software Platform
│   ├── Project Thoth Application
│   ├── Capture Connectors
│   ├── Processors
│   └── Engine Adapters
│
└── Engineering System
    ├── .thoth SDLC standard
    ├── Studio Runbook
    └── Development Runbook

This actually reinforces ADR-001 rather than replacing it. ADR-001 already says the software is an implementation of the methodology rather than the definition of Project Thoth itself.

I would formalize this distinction now.

Otherwise "Project Thoth" will alternately mean:

• the philosophy,
• the methodology,
• the application,
• the repository,
• the corpus,
• the development project,

depending upon which document one is reading.

Your glossary is already intended to prevent exactly this kind of semantic drift.

---

3. Add explicit Product Vision and Product Scope documents

Before requirements, create a short Product Definition.

Your current message contains most of it.

It should define:

Vision

A knowledge-centered generative AI environment in which knowledge and reasoning persist independently of the AI engine consuming them.

Primary differentiator

Engine independence.

Primary user

Initially you.

Primary operating model

Single-user, locally operated, internally designated system.

Primary infrastructure

Forge   → development/client workstation
Gateway → application runtime
Oracle  → replaceable inference appliance
Frontier Providers → external replaceable inference services
Vault   → durable knowledge corpus

Critical product promise

Changing inference engines may change capability and depth, but it must not fundamentally change how Project Thoth works.

That last statement should eventually become both a requirement and a testable acceptance criterion.

---

4. Add actors and system boundaries before identifying use cases

"Identify all Use Cases" is correct, but there is a missing preceding step.

First identify the actors.

At minimum I expect:

Human User

Project Thoth Application

Local Inference Engine
    Ollama today
    Spark/Ollama or successor tomorrow

Frontier AI Provider
    OpenAI
    Anthropic
    Google
    etc.

Knowledge Vault

Capture Connector

External Knowledge Source

Source Control / CI System

Possibly later:

Administrator
Additional Project Thoth User
Processor
Automation
External Application

Then use cases can be organized around actor goals rather than features.

This will greatly improve the requirements document.

---

5. Add Non-Functional Requirements

This is the largest requirements gap.

Use cases tell us what Project Thoth does.

Architecture will be driven just as heavily by how it must behave.

You need explicit requirements for at least:

• Engine independence
• Data portability
• Deployment portability
• Replaceability
• Availability
• Performance
• Security
• Privacy
• Auditability
• Provenance
• Recoverability
• Backup
• Testability
• Maintainability
• Observability
• Configuration management
• Upgradeability
• Browser support
• Accessibility
• Data integrity

Some already exist philosophically. For example, the current philosophy says AI providers must be interchangeable, canonical artifacts human-readable, generated artifacts reproducible, and architecture capable of outliving implementations.

Those principles now need to become engineering requirements.

For example:

NFR-ENGINE-001: Project Thoth SHALL expose inference through a provider-independent application interface.

NFR-ENGINE-002: Replacement of Oracle SHALL NOT require modification of knowledge storage, user interface, Thinking Methodology, or conversation persistence components.

That turns philosophy into something architecture can enforce.

---

6. Add the Thinking Methodology as a first-class product capability

This is especially important.

The current architecture barely contains the system you have developed around:

Constitution
    ↓
Perspective
    ↓
Protocol
    ↓
Channel
    ↓
Voice

Those concepts now exist as substantive Project Thoth intellectual property. The Constitution of Inquiry establishes the reasoning framework and explicitly treats conversations as primary sources of reasoning. Your Perspective and Protocol artifacts already demonstrate that these are modular behavioral components rather than merely prompts.

Therefore your methodology phase should include:

Thinking Methodology Definition

• Constitution
• Perspectives
• Protocols
• Voices
• Channels
• Artifact definitions
• Precedence/order rules
• Composition rules
• Activation rules
• Override/supersession rules
• Storage format
• Versioning
• Runtime assembly
• Engine-independent behavior
• Validation/testing methodology

This should become a requirements source for the application.

---

7. Add Knowledge Architecture requirements explicitly

"Knowledge Management" is presently implied rather than decomposed.

You should define requirements around:

Capture
Preservation
Cataloging
Classification
Collections
Retrieval
Reasoning Context
Processing
Transformation
Provenance
Publishing
Archiving

The existing Source Metadata and Manifest specifications are useful inputs because they already establish the distinction between objective source description and downstream analytical interpretation.

But the application now needs requirements around how those artifacts are:

• created,
• stored,
• viewed,
• edited,
• regenerated,
• related,
• searched,
• fed into inference.

That bridge between knowledge methodology and application behavior is currently missing.

---

8. Add an Engine Abstraction requirements workstream

Given your new product definition, I would make this one of the central requirements workstreams.

The architecture must not think in terms of:

Project Thoth → Ollama

It should eventually resemble conceptually:

                  Project Thoth
                        │
                 Inference Contract
                        │
          ┌─────────────┼─────────────┐
          ▼             ▼             ▼
       Ollama        OpenAI       Anthropic
          │
        Oracle

Oracle itself is not an architectural dependency.

Oracle is a deployment of one provider.

That distinction is crucial because you already expect Oracle to evolve from the current machine to one Spark and potentially several Sparks.

The application should not care.

This should therefore be settled as a requirement before architecture begins.

---

9. Add an Environment and Toolchain Decision phase

Your SDLC section currently jumps from methodology selection to coding standards and CI/CD.

Before Sprint 0, decide the standard engineering workstation.

Questions include:

• VS Code vs Visual Studio Community
• Git workflow
• Gitea project organization
• Package management
• Container development approach
• Local debugging strategy
• Testing framework
• Documentation tooling
• Diagram standard
• API documentation standard
• secrets management
• environment configuration
• dependency update strategy

I would not switch from VS Code merely because this becomes a larger application. That decision should follow the eventual technology stack rather than precede it.

If, for example, architecture leads toward TypeScript/React/Python, VS Code remains entirely sensible.

If you deliberately choose a heavily .NET-centric architecture, Visual Studio Community becomes more compelling.

So defer that decision until the technology architecture is clearer.

---

10. Expand Sprint 0 beyond CI/CD

You describe Sprint 0 as creation of the SDLC pipeline.

I would make Sprint 0:

Prove that the software factory works before using it to build Project Thoth.

It should include:

Repository
    ↓
Branch / change workflow
    ↓
Work Order / issue
    ↓
Developer or AI implementation
    ↓
Local validation
    ↓
Commit
    ↓
Push to Gitea
    ↓
Automated build
    ↓
Automated tests
    ↓
Container build
    ↓
Artifact/version creation
    ↓
Deployment to Gateway test environment
    ↓
Smoke test

The deliverable should be a trivial application running through the entire pipeline.

Not Project Thoth functionality.

Something as simple as:

Project Thoth
Version: 0.0.1
Build: <git-sha>
Status: Healthy

would be enough.

That proves the studio before the studio begins building the product.

---

11. Add software quality and test strategy before development

Your coding standard already calls for unit, integration, E2E, and regression testing.

But the project plan needs a Testing Strategy.

Particularly important for Project Thoth will be:

Deterministic tests

For parsers, serializers, configuration, retrieval, and storage.

Contract tests

For engine adapters.

Every inference provider should satisfy the same Project Thoth engine contract.

Behavioral fidelity tests

This is unusual and important.

You have already defined the requirement conceptually:

Results may differ in depth but fundamentally should be similar.

Eventually you need a test corpus that can ask:

Same:
  conversation
  knowledge context
  Constitution
  Perspective
  Protocol
  Voice
  user request

Run against:
  frontier engine
  local engine

Evaluate:
  Did each follow the methodology?
  Did each use the supplied knowledge?
  Did each preserve provenance?
  Did each satisfy the task?

That is likely to become one of Project Thoth's most distinctive engineering practices.

---

12. Add security and trust boundaries

This is missing completely from the plan and will influence architecture.

At minimum define:

• Where API keys live.
• Whether frontier providers may receive all knowledge.
• Which corpus material may leave the local network.
• How retrieved documents inherit access restrictions.
• Whether logs may contain prompts or documents.
• How application secrets are stored.
• Authentication assumptions.
• Network trust boundaries between Forge, Gateway, and Oracle.
• How imported/captured documents are treated as untrusted content.
• Prompt-injection boundaries.

Given that Project Thoth is fundamentally a Knowledge Architecture product, security cannot be retrofitted after retrieval is built.

---

13. Add configuration and environment separation

Even an internal project should define:

Development
Test
Production

They might initially all live on the same physical hardware, but the logical distinction matters.

You will want containerized configuration such as:

thoth-dev
thoth-test
thoth-prod

or equivalent.

This makes your studio runbook applicable later to GW and future software projects.

---

14. Add architectural decision governance

You already have ADRs, which is excellent.

But define their lifecycle:

Proposed
Accepted
Rejected
Deprecated
Superseded

And establish the rule:

Existing accepted ADRs are never silently rewritten to reflect a new decision.

Instead:

ADR-004 supersedes ADR-00X

That preserves the intellectual history of the project, which is especially appropriate for Project Thoth.

---

15. Add requirements traceability

Because AI will participate heavily in development, I would establish this from the beginning.

Something lightweight:

Business Goal
    ↓
Use Case
    ↓
Functional Requirement
    ↓
Non-Functional Requirement
    ↓
Architecture Component
    ↓
Work Order
    ↓
Test

You do not need heavyweight enterprise tooling.

Markdown IDs are enough:

UC-007
FR-021
NFR-008
ADR-012
WO-034
TEST-091

That makes the repository extraordinarily legible to both humans and AI.

---

16. Separate the two runbooks

Your deliverables identify:

1. Software Development Studio Runbook
2. SDLC Runbook

Keep those separate.

Software Development Studio Runbook

Answers:

How do I create the environment in which software gets built?

For example:

Forge configuration
Gitea
Gateway
Docker
CI runners
SSH
credentials
repository creation
developer tooling
backup
deployment environment

SDLC Runbook

Answers:

Once the studio exists, how do we build software?

For example:

Product definition
Requirements
Architecture
ADR
Sprint planning
Work Orders
Development
Code review
Testing
CI
Release
Deployment
Maintenance
Retirement

That distinction will make these deliverables reusable outside Project Thoth.

---

Revised Project Plan

I would therefore restructure your current plan like this:

0. Reconcile Project Thoth

• Audit existing repository.
• Audit .thoth.
• Audit ADRs.
• Audit specifications.
• Audit existing source code.
• Identify obsolete experiments.
• Establish authoritative current state.
• Record superseded decisions without deleting history.

1. Establish the Software Development Studio

• Define Forge/Gateway/Gitea development topology.
• Select standard development tools.
• Define repository creation procedure.
• Define environment strategy.
• Define secrets/configuration strategy.
• Define backup/recovery expectations.
• Draft Software Development Studio Runbook.

2. Establish SDLC Practices

• Select/adapt methodology.
• Define lifecycle phases.
• Define roles.
• Define ADR process.
• Define Work Order process.
• Define Git/branch/change process.
• Define testing strategy.
• Define Definition of Ready.
• Define Definition of Done.
• Define release/versioning conventions.
• Define requirements traceability.
• Audit/refactor coding standards.
• Draft SDLC Runbook.

3. Redesign .thoth

• Define purpose of .thoth.
• Define required files.
• Define optional files.
• Define numbering system.
• Create .thoth/README.md.
• Define canonical-vs-generated documentation rules.
• Define AI onboarding instructions.
• Reorganize existing documents.
• Update 00-project-state.md.

4. Establish Sprint 0

• Gitea repository.
• CI runner.
• Build pipeline.
• Test pipeline.
• Container pipeline.
• Versioning.
• Deployment to Gateway.
• Health check.
• Smoke test.
• Prove end-to-end SDLC with trivial application.

5. Define Project Thoth Product

• Product vision.
• Product boundaries.
• Actors.
• Infrastructure assumptions.
• Product terminology.
• Engine-independence principle.
• Product success measures.
• Relationship among methodology, application, archive, connectors, processors, and book.

6. Define Project Thoth Methodology

• Review philosophy.
• Define Knowledge Architecture.
• Define Archiving Methodology.
• Define Thinking Methodology.
• Define Constitutions.
• Define Perspectives.
• Define Protocols.
• Define Voices.
• Define Channels.
• Define artifact specifications.
• Define composition and precedence.
• Identify which concepts require application support.

7. Develop Requirements

• Actor catalog.
• Use-case catalog.
• Detailed use cases.
• Functional requirements.
• Non-functional requirements.
• Security/privacy requirements.
• Knowledge requirements.
• Engine abstraction requirements.
• Deployment requirements.
• Data requirements.
• Operational requirements.
• Behavioral-fidelity requirements.
• Acceptance criteria.
• Requirements traceability matrix.

8. Architecture Readiness Review

This is where this project plan ends.

Confirm:

• Product boundary is stable.
• Major use cases are understood.
• NFRs exist.
• Thinking Methodology requirements exist.
• Knowledge Architecture requirements exist.
• Engine independence is formally defined.
• SDLC is operational.
• Sprint 0 pipeline works.
• .thoth can onboard a new human or AI developer.
• Major architectural unknowns are identified.
• Existing ADR conflicts are resolved.

Then:

Formal Project Thoth Architecture begins.

---

One important change in emphasis

I would not call what happens before architecture "pre-development."

You are already developing Project Thoth.

The software implementation has not begun, but requirements, specifications, ADRs, methodology, test strategy, development infrastructure, and the .thoth system are all engineering artifacts.

That distinction matters because one of the things you are practicing here is precisely what gets lost in many AI-driven projects: software engineering is not synonymous with writing code.

And that may ultimately be one of the most reusable lessons from Project Thoth for the studio model.

The immediate next artifact I would create is not the requirements document. It should be the new .thoth/README.md, because that document can establish the document taxonomy, numbering scheme, authority hierarchy, and instructions governing all the work that follows.