Architecture

Architectural state

Concise description of the current state of the project: what is public, what is not, and how the available elements are related.

I. Principles

Structural principles

The project does not present itself as a single fully public system. The public site, FridaDev as a public application repository, and Frida_V4 as non-public ongoing work have to be distinguished. The principles below keep that description coherent.

This coherence also applies to the project's technical doctrine: the pipeline is treated as the place of an encounter between user text, memory, documents, intermediate states, and validation. The task of the architecture is to make that encounter explicit, distributed, and revisable.

Principle Description
Explicit public status The site must distinguish what is public, what is not, and what is public only as an isolated document.
Distinct material statuses A trace, a summary, a retrieved snippet, an injected document, an operator log, or a research document do not play the same role.
Modular decomposition When the project describes a runtime, it describes separated responsibilities as far as possible: orchestration, memory, summaries, retrieval, validation, documents, LLM, local tooling.
Encounter coded in the pipeline The user prompt is treated as a text, and the pipeline as the technical space where memory, temporality, validation, and revision are organised.
Persistence and streaming are described Conditions of canonical persistence and streaming contracts are treated as architectural elements in their own right.
Observability Logs, audits, administration surfaces, and persistence states are described as parts of the architecture.
Evaluation before assertion The site should not attribute properties to a module unless they are supported by available code, documents, or evaluation.

II. Organisation

Layers and modules

The elements currently mentioned on the site can be ordered as follows: a public documentation site, a public application repository, a non-public application repository, and a few public documents dealing with modules or working problems.

Public site descriptive pages · public documents · contact
↕
Shared problems dialogue · memory · documents · validation · temporality
↕
FridaDev public · Python/Flask · memory · streaming · admin
Frida_V4 non-public · Swift/macOS · modules · voice · documents
Public documents audit · pipeline · contracts · M6 article
Module Main function Status
FridaDev Public repository. Python/Flask web runtime, browser chat, memory, hermeneutic branch, streaming, canonical persistence, and administration surfaces. active
Frida_V4 Non-public ongoing work. Native macOS runtime in Swift, organised by modules, with memory, documents, voice, TTS, and local tooling. non-public
frida-ai Public bilingual site. Current function: project description, public document index, and explicit distinction of availability status. online
M6 Stimmung A working module associated with Frida_V4. The M6 paper is public on this site; the code and repository to which it belongs are not public at this time. public paper
Public documents Audits, runtime cartographies, streaming contracts, operational references, and a working paper. active

III. Invariants

System invariants

The invariants below govern the way the site should speak about the project.

  1. The site distinguishes systematically between what is public, what is not, and what is public only in documentary form.
  2. The site does not present as accessible a repository or module that is not accessible.
  3. Trace, summary, injected document, retrieved snippet, judgment signal, and execution log are not conflated in the description.
  4. A dialogic or hermeneutic signal is not presented as evidence in itself.
  5. Persistence and streaming contracts are treated as architectural elements in their own right.
  6. Observability and administration surfaces are described when they actually exist in the public repository.
  7. The site does not attribute to the project a fictional software unity when its elements have different statuses.
  8. Strong claims about a module should be traceable to an available document, repository, or evaluation.
  9. Possible metrics do not replace a situated reading of the dialogue; they accompany it.

IV. Tensions and open questions

Problems currently under exploration

The following questions remain open in the project.

  • Passage from public repository to non-public work. How should continuities between FridaDev and Frida_V4 be described without suggesting identical public availability?
  • Evaluation of M6. How should the effect of a dialogic regime module on coherence, revision, and non-overinterpretation be measured?
  • Exegetical criterion. How can a qualitative reading of dialogue be articulated with local metrics without reducing system validity to a single family of indicators?
  • Memory and documents. How should memory, summaries, and injected documents be articulated without confusion of status?
  • Voice, local tools, security. How should non-public capabilities related to voice or local tooling be described and evaluated before they are opened?
  • Publication. How can a paper or document be made public about a module whose source repository is not yet open?
See FridaDev ↗ Documents