Break difficult problems into clear responsibilities.
Large systems are divided by responsibility so it is explicit what each component owns before implementation begins.
SHUSHULAB / RESEARCH & ENGINEERING
From research to systems people can actually use.
ShushuLab designs, builds, and operates autonomous development infrastructure, production web systems, an agent runtime, and audio software. Across these different domains, the same questions guide the work: who owns each responsibility, what happens when something fails, and what evidence shows that it actually works.
If this is your first visit, the four areas below are enough to understand the big picture. Technical design details are available only when you want to go deeper.
START HERE
What does ShushuLab actually do?
The work is not split into research, coding, and operations as unrelated activities. Problems are taken from definition through implementation and into a state that can be tested and operated.
Go beyond the prototype.
For web systems that means production operation; for autonomous infrastructure, recovery after failure; for audio software, use inside a real production workflow.
Use evidence, not only intuition.
Decisions are backed by reproducible tests, Windows/Linux CI, operational behavior, and research evidence appropriate to the problem.
FOUR AREAS
Different domains, one connected engineering approach.
Start here without worrying about the specialist vocabulary.
01 / RELIABILITY
Let AI work for a long time without turning failures into uncontrolled repetition.
An infrastructure layer watches autonomous development work, classifies failures, saves progress, stops unsafe repetition, and resumes only from a known state.
Autonomous Development Infrastructure 02 / PRODUCTIONRun work records, contracts, billing, and payments in one production web system.
ShushuLab's own operational platform connects work tracking with contracts, signatures, billing, payments, and product operations.
ShushuLab Production Platform 03 / AGENT RUNTIMEDo not let an AI model alone define whether the same agent continues to exist.
An agent runtime keeps continuity, responsibility, history, and action boundaries outside the replaceable language model.
Kizuna Engine / POE 04 / AUDIO SOFTWARETurn repetitive or unstable vocal-production work into software with clear roles.
Editing automation, input standardization, and character shaping are designed as separate product responsibilities rather than one all-purpose processor.
Vocal Prep / Formant Preamp / VahluneWORKING EVIDENCE
There are running systems and products behind the explanation.
These are the easiest concrete points to verify without reading the deeper architecture first.
A production web platform
Work Log, workspace authorization, contracts and e-signatures, billing and refunds, Stripe, mail, and PDF generation are operated as parts of the ShushuLab service.
View Work Log →Continuous Windows / Linux verification
Changes are tied to specific commits and verified in Windows and Linux CI before production handoff. Recovery and re-execution are treated as separate responsibilities.
POE / Kizuna Engine — Live implementation
This is the running implementation of a runtime that keeps agent continuity, history, and responsibility outside the replaceable model. Click to open the live “Yotogi no Hakoniwa” World. The paper is Submitted to AAMAS 2027 as Submission #1817.
Audio software products
Vocal Prep, Formant Preamp, Vahlune, and related products are developed and tested as Windows VST3 software and connected to ShushuLab product routes.
View audio products →GO DEEPER
Technical detail is here when you need it.
The sections below start with plain-language answers. Open “View technical details” only when you want the architecture, failure modes, and design decisions.
01 / AUTONOMOUS DEVELOPMENT
Autonomous Development Infrastructure
Long-running AI development work will eventually encounter crashes, repeated failures, stalled progress, and uncertain state. This infrastructure is designed around those failures rather than assuming they will not happen.
What was built?
A separated execution, monitoring, checkpoint, recovery, failure-classification, retry, and CI-verification system for autonomous development work.
Why is it needed?
The more autonomy a system receives, the more important it becomes to define when it must stop, what evidence is required to resume, and what must be true before production handoff.
What is the evidence?
It is used across ShushuLab and related development lines with commit-specific CI checks, crash recovery, and no-progress detection.
View technical details
- Problem
- Long-running autonomous development can fail through process crashes, authentication/quota/provider faults, repeated failures, no-progress loops, dirty or divergent state, and deployment before the verified commit is known.
- Architecture
- The system combines worker / watchdog / checkpoint / recovery / circuit breaker mechanisms, failure classification, bounded retry and cooldown, repeated-failure and no-progress detection, exact-SHA CI verification, self-hosted Windows/Linux runners, Linux/systemd, and separated deployment/rollback paths.
- Failure modes
- Uncertain sessions after a crash, repeated work without progress, provider failures, branch divergence, dirty working trees, and mismatch between the CI-tested SHA and deployed SHA are treated as explicit failure states.
- Decisions
- Ambiguous state fails closed. Worker execution, CI authority, and production deployment are separated; checkpoints and integrity fingerprints must establish a safe continuation point before work resumes.
- Evidence
- This infrastructure is used across ongoing ShushuLab and related development lines to run repairs, tests, exact-head CI, and recovery workflows.
- Result
- The result is an autonomous development process that can increase machine initiative without losing responsibility boundaries or restart conditions after failure.
Research status: working paper / manuscript in preparation. It is not described as accepted or published.
02 / PRODUCTION PLATFORM
ShushuLab Production Platform
ShushuLab is more than a public site. It is a production web platform that actually handles work records, contracts, billing, payments, and product operations.
What was built?
A Java 21 / Spring Boot system connecting Workspace roles, Orders, Quotes, Contracts, e-signatures, Work Log, Billing / Refund, Stripe, mail, and PDF generation.
Why is it needed?
Money, contracts, and customer data require clear boundaries for who may view, change, or act through a public link.
What is the evidence?
The system is operated on Ubuntu VPS / systemd / HTTPS / Cloudflare and covered by regression tests for authorization, payments, webhooks, and public-token boundaries.
View technical details
- Problem
- When projects, work logs, quotes, contracts, signatures, billing, refunds, and product payments live in separate systems, authorization, state, and evidence fragment across the workflow.
- Architecture
- Java 21 / Spring Boot / Spring Security provide Workspace roles and connect Order / Quote / Contract / e-signature / Work Log / Billing / Refund with PDF generation, Resend, Stripe Checkout / Subscription / Webhook integration.
- Failure modes
- Cross-workspace leakage, VIEWER/GUEST authority drift, public-token escalation into management access, duplicate webhooks, inferred payment state, and mismatch between verified and deployed commits are treated as explicit system boundaries.
- Decisions
- Authentication, authorization, product association, subscription, and entitlement are separated. Public documents retain token boundaries; production runs on Ubuntu VPS / systemd / HTTPS / Cloudflare with CI/CD and rollback-aware deployment.
- Evidence
- The current ShushuLab repository and public service contain the implemented Workspace, e-signature, Work Log, billing, Stripe, mail, PDF, and CI/CD flows with regression coverage.
- Result
- Operational data and commercial flows are connected in one production system while preserving workspace-scoped authority.
03 / AGENT RUNTIME ARCHITECTURE
Kizuna Engine / POE
Kizuna Engine / POE keeps history, responsibility, and action continuity in the runtime architecture instead of assuming that the AI model itself is the persistent subject. The heading opens the running “Yotogi no Hakoniwa” implementation.
What was built?
A Java 21 agent runtime that separates World, Subject, Runtime, and Capability, treating the language model as a replaceable capability.
Why is it needed?
Model replacement, memory copies, forks, and crash recovery raise a basic question: is this still the same subject, and where does responsibility for earlier actions remain?
What is the evidence?
The Java 21 implementation is used as a constructive witness, and the paper “Externalizing the Subject: Lineage, Responsibility, and Evidence Across Agent Lifecycle Changes” is Submitted to AAMAS 2027 as Submission #1817.
View technical details
- Problem
- Model replacement, context discontinuity, shared models, copied memory, clone/fork operations, and unresolved effects after crashes make continuity and responsibility ambiguous if identity is left implicit in the LLM.
- Architecture
- The dependency direction is World → Subject → Engine → Runtime → Capability. Presence, action authority, lineage, checkpoint/recovery, and managed effects belong to the runtime architecture rather than to a specific model.
- Failure modes
- Multiple canonical heads, treating copied memory as the same subject, replaying unresolved actions, and equating a model change with a subject change are treated as architectural failure modes.
- Decisions
- Subject continuity is externalized from the model through single-head lineage, explicit Recover / Clone / Fork semantics, authorization and attribution of Actions, and reconciliation of unresolved effects before new task-effectful work.
- Evidence
- The Java 21 implementation is used as a constructive witness for Subject / Runtime / Capability separation, lineage, recovery, and managed-effect boundaries.
- Result
- The architecture makes model-independent continuity explicit as a history-bearing runtime process with responsibility and effect boundaries.
PaperExternalizing the Subject: Lineage, Responsibility, and Evidence Across Agent Lifecycle Changes
AAMAS 2027 Submission #1817 / Submitted. This does not indicate acceptance or publication.
04 / AUDIO SOFTWARE & R&D
Audio Engineering
Audio Engineering turns problems from real vocal-production work into software with distinct responsibilities instead of asking one processor to “make everything better.”
What was built?
Vocal Prep, Formant Preamp, Vahlune, and related work built with C++20 / JUCE 8 / CMake / Visual Studio / Windows VST3.
Why is it needed?
Editing automation, input standardization, and character shaping have different goals. Mixing those responsibilities makes both control and evaluation harder to reason about.
What is the evidence?
Development, validation, and held-out evidence are separated; machine measurements and human listening are treated as different gates before product build, test, and productization.
View technical details
- Problem
- Repetitive editing, input variability, unstable front-end conditions, and character shaping become difficult to evaluate when a single processor is expected to own every responsibility.
- Architecture
- C++20 / JUCE 8 / CMake / Visual Studio / Windows VST3. Vocal Prep owns editing automation, Formant Preamp owns front-end standardization, and Vahlune is limited to harmonics / tone / character.
- Failure modes
- Local metric gains, overfitting to development evidence, authority conflicts between standardization and character, and disagreement between machine measurements and DAW usability are treated as evaluation failures.
- Decisions
- Development / Validation / Held-out evidence is separated, with baselines, hypotheses, deterministic fixtures, predeclared acceptance rules, negative-result preservation, and a human listening gate.
- Evidence
- Vocal Prep, Formant Preamp, and Vahlune are developed through existing product and validation paths, with Windows VST3 build, test, and productization workflows.
- Result
- The resulting product chain separates editing automation, input standardization, and character shaping into distinct engineering responsibilities.
KNOWLEDGE / METHODS
Publish the reasoning behind the implementation.
Knowledge collects practical notes on observation, judgment, control, acoustics, and other methods that inform the implementation and production work.