The build log of a cognitive system.
A plain-English record of how Viventium is becoming faster, more reliable, more expressive, and more useful over time, grounded in public docs, QA evidence, and project history through May 25, 2026.
Viventium is designed to feel like one mind in conversation, with specialist reasoning running in parallel without fighting for the interface.
The product should respond immediately, then deepen the result in the background when the task deserves more work.
Memory, scheduling, follow-through, and project state should make Viventium more useful over time instead of resetting every session.
Work that is public-safe, documented, and backed by the current release evidence.
User-visible capability that has meaningful coverage and still needs broader real-path proof.
Important work with shipped foundations and active reliability follow-through.
What this means
- A delegated task can live in a named Workspace instead of disappearing into a black box.
- Users can watch progress, steer the worker, pause or resume work, and download generated artifacts.
- Team and managed deployments now have stronger tenant scoping, signed View/Steer links, artifact protections, idle controls, and provider guardrails.
Reliability note
Standard GlassHive QA records strong local and approved-deployment coverage, with the broader provider/cloud matrix still marked partial rather than overclaimed.
Technical detail and receiptsOpenClose
- The latest public pin moves GlassHive to the hardened worker/provider bootstrap and Workspace UI contracts.
- The work covers signed operator and artifact links, owner-scoped upload materialization, path traversal denial, metadata endpoint blocking, default worker/profile guardrails, and latest-result wait/status behavior.
- The user-facing model leads with Workspaces while worker ids, sandbox details, raw noVNC links, and provider plumbing stay diagnostic.
Focus areas
Reader lens
Start with the meaning. Open the technical receipts when you want the implementation trail.
What this means
- Viventium should not speak raw source labels, URLs, emails, citation ids, code fences, or isolated punctuation.
- Telegram voice replies now follow the same speech-safety rules as the browser LiveKit voice path.
- Expressive providers can still use emotion, speed, break, spell, and laughter controls when they truly support them.
Reliability note
Provider-payload and sanitizer parity passed on May 22; the live Telegram bot send/listen path remains a user-path follow-up.
Technical detail and receiptsOpenClose
- Cartesia Sonic-3 routes preserve supported emotion markup and the [laughter] marker, including matching emotion configuration at the provider boundary.
- xAI speech tags stay isolated from Cartesia markup, while plain OpenAI/ElevenLabs fallback routes strip unsupported voice controls before synthesis.
- Telegram provider-payload tests cover voice-note replies, always-voice text replies, proactive callback audio, and provider-specific sanitizer behavior.
Focus areas
Reader lens
Start with the meaning. Open the technical receipts when you want the implementation trail.
What this means
- A single Start Chat action now covers room connection and post-connect microphone enablement instead of requiring awkward retries.
- Cold voice settings and startup route compilation have bounded retry behavior instead of indefinite loading.
- Local Whisper work improved exact-model validation, prewarm, latency visibility, and interruption behavior.
Reliability note
One-click startup, cold settings, and local Whisper barge-in have targeted passes; the full authenticated end-to-end spoken answer remains marked partial in current QA.
Technical detail and receiptsOpenClose
- Call-session state tracks dispatch, microphone, room, worker job, stream ids, and provider route metadata more explicitly.
- The modern LiveKit playground is the default voice UI; the old playground is only selected when an operator explicitly asks for it.
- Local RAG/search resource guardrails were added around this same release so voice and recall do not silently claim unhealthy backends as usable.
Focus areas
Reader lens
Start with the meaning. Open the technical receipts when you want the implementation trail.
What this means
- The website can say what shipped, what is in validation, and what is still being hardened without hiding messy reality.
- Each major surface now has a home for expected behavior, forbidden regressions, and last-run status.
- Public evidence is written to be reviewable without leaking private user data, local machine paths, screenshots, tokens, or raw logs.
Reliability note
This is not a feature claim by itself; it is the framework that keeps later feature claims honest.
Technical detail and receiptsOpenClose
- The Runtime Feature QA Map ties requirement docs to QA owners, cases, reports, user-grade surfaces, and open follow-through items.
- Reusable QA templates and case catalogs now cover voice, Telegram, memory, recall, web search, MCPs, GlassHive, Prompt Workbench, branding, release readiness, and more.
- The completion bar explicitly distinguishes source inspection, unit tests, logs, DB/state, browser QA, and real user-path evidence.
Focus areas
Reader lens
Start with the meaning. Open the technical receipts when you want the implementation trail.
What this means
- Behavior changes can be reviewed instead of quietly drifting between source files and live agents.
- Prompt edits can create drafts, run evals, and compare live/source state before anything is pushed into the running assistant.
- Private scheduled prompt objects are visible and inspectable, while the latest local nightly deep-thought run remains an active hardening item.
Reliability note
Workbench source/live/eval visibility is active; the Workbench-private Subconscious Deep Thought schedule is visible but currently not delivering reliably in the May 25 local QA report.
Technical detail and receiptsOpenClose
- Core surfaces include Prompt Atlas, Prompt Flow, Monaco Prompt Detail, Live Drift Board, Draft Review, Eval Designer/Results, Prompt Traces, and Scheduled Prompts.
- The workbench keeps Source, Live, and Evaluated states separate and uses the guarded prompts-only sync helper for reviewed pushes.
- Memory-related prompts moved into the registry, including transcript summarizer, transcript caveat, and memory hardener consolidation prompts.
Focus areas
Reader lens
Start with the meaning. Open the technical receipts when you want the implementation trail.
What this means
- Viventium can use meeting history without blindly believing every sentence as a permanent fact.
- Processed transcript inventories help the assistant know what transcript evidence exists before answering broad recall questions.
- Recent chat corrections and direct user statements can outrank stale transcript-derived claims.
Reliability note
Transcript recall and inventory QA has multiple passes; the May 25 health review still marks transcript vector backfill partial with a small capped backlog remaining.
Technical detail and receiptsOpenClose
- Transcript summarization, inventory artifacts, source labels, vector-presence checks, and summary-only RAG all gained dedicated cases.
- Transcript contents are treated as data, not instructions, so prompt-injection-like meeting text does not become system behavior.
- The memory hardener can read transcripts and Listen-Only ambient records as soft evidence, with corroboration requirements before durable memory writes.
Focus areas
Reader lens
Start with the meaning. Open the technical receipts when you want the implementation trail.
What this means
- Wing Mode lets Viventium stay present in a live call without jumping into every overheard comment or vulnerable bit of self-talk.
- Listen-Only Mode lets a room be transcribed and saved for later memory consolidation without live replies, tools, background agents, or memory writes firing in the moment.
- The system can spend fewer tokens and behave more respectfully because silence is a first-class behavior.
Reliability note
The contracts are documented and eval-covered, but the native voice-surface validation remains ongoing where cases still call for real user-path proof.
Technical detail and receiptsOpenClose
- Both modes are persisted call-session flags; enabling one clears the other.
- Listen-Only entries are structured ambient transcript records with zero token count, no normal recall indexing, and special metadata for later memory hardening.
- Wing Mode suppresses background cortex activation for ambient turns, so presence does not become hidden computation.
Focus areas
Reader lens
Start with the meaning. Open the technical receipts when you want the implementation trail.
What this means
- Users get more practical voice choices without the system secretly changing the route they selected.
- A route that supports expressive speech controls can keep them; a plain route strips them before the audio provider sees them.
- Fallbacks can recover from provider problems without producing mixed-provider or markup-filled speech.
Reliability note
The routing rules are shipped as explicit contracts so provider choice does not depend on prompt-text or provider-name heuristics.
Technical detail and receiptsOpenClose
- Provider capability contracts describe which speech controls each route can accept.
- xAI standalone TTS is separate from the older Grok Voice Agent adapter and uses its own speech tag dialect.
- Config compiler and runtime tests keep generated provider routes aligned with the selected install and voice settings.
Focus areas
Reader lens
Start with the meaning. Open the technical receipts when you want the implementation trail.
What this means
- A user can delegate work, keep moving, and still get the result back in the originating surface.
- The assistant can acknowledge the task briefly instead of exposing worker ids, ports, queues, and terminal plumbing.
- Results can survive refreshes, restarts, and longer worker runs instead of vanishing when the first chat response ends.
Reliability note
The callback contract is shipped across GlassHive host workers and Viventium surfaces, with QA focused on visible result delivery rather than raw runtime chatter.
Technical detail and receiptsOpenClose
- GlassHive callback metadata is projected through request context and signed before return delivery.
- Callback persistence, retry/backoff, replay protection, and surface delivery ledgers make completion delivery more durable.
- Final reports, artifacts, approvals, cancellations, and failures are terminal/actionable events; lifecycle noise stays internal.
Focus areas
Reader lens
Start with the meaning. Open the technical receipts when you want the implementation trail.
What this means
- A current-fact answer should use real search evidence or say why the lookup path is degraded.
- Scheduled work gained catch-up and truthfulness rules so missed or stale runs are not papered over.
- The public QA layer now records when a time-based routine is failing instead of pretending reliability is solved.
Reliability note
Truthfulness rules shipped, but the May 25 local health review still marks user-level scheduler delivery and Prompt Workbench deep-thought scheduling as failed.
Technical detail and receiptsOpenClose
- The work covered scheduler misfire catch-up, scheduled live-fact truthfulness, web-search tool preservation, and search failure classification.
- Local search checks distinguish Docker state, SearXNG, Firecrawl, hosted provider auth, rate limits, empty results, and unavailable prerequisites.
- Recent local QA still shows user-level scheduler routines stale, so the page marks this as active hardening rather than a finished reliability claim.
Focus areas
Reader lens
Start with the meaning. Open the technical receipts when you want the implementation trail.
What this means
- Install and upgrade paths gained more honest readiness checks and recovery behavior.
- Remote access guidance became more explicit about safe public-facing setup and caveats.
- Telegram, restore, and modern voice playground work moved closer to the expectation that local-first should recover cleanly instead of depending on one machine state.
Reliability note
This cluster is foundational reliability work: less glamorous than a feature demo, but necessary for a local-first system people can actually run.
Technical detail and receiptsOpenClose
- Installer readiness, preflight, doctor, component bootstrap, helper behavior, and generated config boundaries were tightened.
- Telegram local Bot API support and detached supervision work improved media/runtime reliability.
- Continuity-aware backup restore and release guardrails separated source correctness from generated or installed runtime state.
Focus areas
Reader lens
Start with the meaning. Open the technical receipts when you want the implementation trail.
What this means
- The project gained a real public starting point instead of a private-only experiment.
- Users and reviewers can reason about what is public-safe, what is generated locally, and which components are pinned.
- The local-first story starts with install, configuration, verification, and trust boundaries before broader autonomy.
Reliability note
This is the foundation that later voice, memory, Workspaces, and QA work build on.
Technical detail and receiptsOpenClose
- The baseline includes the public installer, bin/viventium command surface, config schema, compiler, doctor flow, components.lock.json, approval manifests, and release policy checks.
- Public/private/enterprise boundaries became explicit so docs, QA, fixtures, examples, and commits do not leak private operating context.
- Secret scanning, config compilation tests, and release-readiness docs became part of the public review path.
Focus areas
Reader lens
Start with the meaning. Open the technical receipts when you want the implementation trail.