Back to the main page

Real-Time Teacher-Led Adaptive Learning

The lesson stays human. Its evidence keeps moving.

Live context stays on the device. When a session closes coherently, traceable evidence can enter durable memory and later return as a small, scoped packet for a teacher decision.

What continues after the call

The call ends. The learning path does not.

The original lesson moment, a teacher-confirmed correction, later recall and the next decision stay connected. Each step belongs to the same human-led learning path.

The teacher notices and decides. LingoSide preserves where the evidence came from, brings back the relevant part and leaves room to say there is not enough evidence.

See the product layers
  1. 01

    During the lesson

    Observe the lesson

    Support the moment without taking over the conversation.

    Keep source text, translation and contextual reply suggestions in a sidecar that takes one glance, so a meaningful phrase, correction or difficulty can be noticed while the conversation keeps going. Earlier moments from the same session inform what is suggested.

  2. 02

    After the lesson

    Keep what happened

    Turn the conversation into structured learning evidence.

    Preserve the session as a finalized record: saved phrases, teacher-confirmed corrections and evidence-linked moments. Every item keeps a pointer to the exact utterance it came from, so it can be checked against the lesson instead of taken on trust.

  3. 03

    Between lessons

    Practise it later

    Practice through retrieval, not passive re-reading.

    Ask the learner to retrieve first, then reveal the source moment and its context. Selected material comes back at useful intervals and in the situation where it first mattered, rather than as another generic list of exercises.

  4. 04

    At every teaching proposal

    Teacher decides

    AI proposes a hypothesis. The teacher decides what it means.

    Show the teaching proposal together with the lesson moment behind it, so the teacher can approve, edit or reject it. That decision, not the model’s confidence, is what the rest of the loop builds on.

  5. 05

    Before the next lesson

    The next lesson adapts

    Let the next conversation build on the last one.

    Bring the right earlier material back into reach: due reviews, saved phrases, open corrections and possible patterns, each one leading to the evidence behind it. LingoSide is building this stage so that earlier decisions support better choices for learner and teacher, without turning the lesson into a dashboard or an automated course.

Evidence-based memory

Memory that can point back to the moment.

LingoSide does not need to remember everything. It preserves useful lesson evidence and the teacher’s correction, and it is building the memory of what comes next: the learner’s later recall and what happens when the language returns.

01

Evidence

A phrase, correction or difficulty remains linked to the source utterance.

02

Correction

Teacher confirmation, edits and rejection become part of the record.

03

Recall

The learner tries to retrieve before seeing the answer and context again.

04

Later use

The loop is designed to distinguish independent recall, transfer, prompted use and no attempt.

Evidence before inference

An observation can be checked against the lesson moment that supports it.

Corrections propagate

When a teacher corrects or removes an item, later views are designed to use the corrected record.

Uncertainty stays visible

A hypothesis is not presented as a fact about the learner.

Teacher authority

The teacher does the teaching. LingoSide keeps the evidence ready.

LingoSide can surface a traceable moment and a possible next move. The teacher reads the learner, chooses the timing and decides what happens in the lesson.

Signal Moment Hypothesis Strategy Teacher decision Later outcome

Observation

The learner recognises a phrase but cannot retrieve it while speaking.

The lesson evidence suggests a retrieval problem, not proof of a broad weakness.

Possible strategy

Bring the phrase back through active recall in a related conversation.

ApproveEditReject

Under the hood

LingoSide is designed to recall the right evidence—not reread everything.

During a lesson, LingoSide serves the active working set from client RAM. With session archiving enabled (the default), it checkpoints finalised content locally. After the session closes coherently, its Evidence is intended to enter the backend index for durable, correctable recall across lessons.

For everyone

Think of it as a librarian with a strict access card: search only the right learner and course, combine exact-word and meaning matches, then hand the AI a few traceable excerpts—not the whole history.

Lesson evidence Access scope Structured filters Text + meaning search Order Evidence by relevance Evidence packet or abstain

Established terms, one architecture

RAM + default-on local checkpoints + backend memory

Short-term and long-term memory with hybrid retrieval (RAG)

RAG (retrieval-augmented generation) means that before AI helps, a retrieval layer looks for relevant Evidence instead of pouring the whole transcript history into the prompt. The terms below name separate parts of the architecture; together they describe LingoSide’s design, not a new industry standard.

Short-term / working memory
The active working set for the current lesson is served from client RAM for low-latency recall. When session archiving is enabled (the default), finalised lesson content is checkpointed locally while the lesson runs. After a crash or restart, the latest valid checkpoint remains available as an incomplete session record, not as an automatically resumed live lesson.
Long-term / durable memory
Only after a session closes coherently is its Evidence intended to enter the backend index for cross-lesson recall and later correction. That is a long-term indexing gate, not the first time lesson content is saved.
Hybrid retrieval
Full-text search (FTS) finds exact words; embeddings find semantic matches. Their candidate sets are combined before Evidence is ordered by relevance.
Metadata filtering
Server-side authorisation restricts candidates to the requester, learner and course before search. This access boundary is also described as scoped retrieval.
See how five language apps answer the same ten questions
  1. Preserve evidence, not guesses

    Finalised moments keep their speaker, language, time and source. Across lessons, a raw transcript or AI hypothesis is not treated as a fact: teacher confirmation, uncertainty and correction status stay explicit.

  2. Authorise, filter & retrieve

    The server limits candidates to the permitted learner and course before Evidence is ordered. Structured fields remove invalid or superseded items; full-text search (FTS) and embeddings then find exact and semantic matches.

  3. Select Evidence, cite or abstain

    Time, review state, teacher-confirmed corrections and the current lesson goal can change the order of Evidence candidates. The consumer receives only top-k Evidence with provenance and why it matched—or no result when confidence is too low.

Access is checked before retrieval, so only authorised people can read learner-and-course memory.

Corrections and invalidations affect recall, so stale evidence does not quietly return.

Corpus size is not prompt size: AI receives a small, traceable packet instead of the whole history.

In deployment terms, the edge–cloud split has two client-side layers: RAM serves latency-sensitive working state, while default-on local session checkpoints protect finalised lesson content during the session. Only after the session closes coherently is cross-lesson Evidence intended to enter the server-side index. That topology is separate from hybrid retrieval, which describes how backend Evidence is found.

One corpus is not one giant prompt

Structured filters, FTS and embeddings generate Evidence candidates; temporal and lesson-goal signals order them by relevance. Only the best small packet reaches the consumer. A larger history does not require GraphRAG or a longer context window by default.

Memory stays correctable

Every retained item keeps its source, date, language, status and teacher decision. A correction creates a new version; invalidated or superseded evidence leaves active recall without erasing the audit trail.

Authorisation comes before similarity

Search is scoped on the server to the requester, learner and course before Evidence is ordered by relevance. Without the required grant, a requester sees nothing, however similar the text may be.

Session boundaries

Your lesson does not queue behind anyone else’s.

The learner sidecar holds no provider key of its own. It sends one speech stream for live recognition, from the source selected for the lesson: the learner microphone or system audio from the lesson call. The teacher sidecar reads the shared lesson state and opens no audio connection.

Two connected sidecars. One speech stream from the learner sidecar: the source selected for the lesson, its microphone or system audio from the lesson call. It goes directly to the STT provider for live recognition. The teacher sidecar reads the shared lesson state, transcript and teaching support; it sends no audio.

Audio producer Learner sidecar Learner microphone or system audio from the lesson call
one speech stream from the selected source: microphone or system audio from the lesson call
Live recognition STT provider Audio is sent directly from the learner sidecar to the STT provider; it is not relayed through the LingoSide backend.
Read-only audio role Teacher sidecar No microphone or system audio sent
Shared between both sidecars Lesson state Transcript and teaching support

The app carries no key

The Windows package is built without a provider key inside it, so it cannot connect to anything on its own. It has to ask the backend first, every single time.

A pass per connection, not a permanent key

Each connection attempt gets its own pass that expires about a minute later. Nothing long-lived sits on the computer waiting to be copied or reused.

Your audio does not pass through us

The backend opens the session, issues the pass and records what happened. The sound itself goes directly from your machine to the recognition service, so there is no shared middle stop to wait behind.

For a teacher this means one practical thing: putting a lesson through LingoSide does not drop it into a shared pipe, and it does not leave a reusable key sitting on the computer afterwards.

Where it runs

One product. Four platforms. One codebase.

A lesson behaves the same wherever it runs, because this is not four products pretending to be one. The sidecar is a single application compiled for each system.

Windows

The desktop sidecar, delivered as a signed package that updates itself in the background.

macOS

The same desktop sidecar on Apple hardware.

Android

A phone beside the lesson rather than a second screen to manage.

iOS

The same phone-sized sidecar on iPhone and iPad.

Written in Flutter

Flutter is Google’s open-source toolkit for building one application in Dart and compiling it into a real native app for each operating system — not a website in a wrapper. LingoSide uses it for the whole sidecar, so the lesson logic, the interface and the backend contracts live in one codebase instead of four. That is why adding a platform is mostly packaging, permissions and store rules rather than rebuilding the product.

The learner sidecar sends one speech stream for recognition, from the source selected for the lesson: its microphone or system audio from the lesson call. The teacher sidecar reads the shared lesson state and sends no microphone or system audio.

Technology behind LingoSide

Powered by

Data architecture

One event path. Four distinct responsibilities.

Events move through the system, but their meaning stays owned. Stream processing, the learning-data warehouse, AI diagnostics and product analytics remain separate by design.

Domain event path

From client event to answerable state.

In the target architecture, the client event stream enters Proton, where streaming SQL shapes live events and sends durable batches to ClickHouse.

  1. Client event stream Typed lesson events carry a stable event ID, schema version and idempotency key.
  2. Proton ingress / NativeLog Target architecture: Proton receives the client event stream, applies streaming SQL and sends durable batches downstream.
  3. ClickHouse RAW Append-oriented event and evidence history.
  4. Versioned derivation Explicit, versioned computation turns evidence into projections and state.
  5. Serving / Derived Rebuildable projections, aggregates and current learner state.

Proton OSS

Real-time event processing

Proton OSS is Timeplus’s Apache 2.0 open-source streaming SQL engine: a single C++ binary with no JVM or ZooKeeper. The target architecture assigns it the client event stream and streaming SQL, with durable batches routed to ClickHouse.

Evidence for our own benchmark—not a capacity promise.

Why a separate layer

The live stream can absorb pressure and be replayed without making the domain depend on a stream engine API.

ClickHouse

Domain warehouse: RAW + Serving

The target architecture assigns ClickHouse the durable learning-data warehouse—not the live stream, AI trace store or product telemetry.

RAW · evidence history

Append-oriented events and educational evidence. New interpretation never overwrites the historical record.

Serving / Derived · usable state

Rebuildable projections, aggregates and current learner state used by the backend.

Same RAW + same derivation version → same semantic state.

Why a separate layer

Evidence stays auditable; current state can change and still be reproduced from history.

Langfuse

AI execution observability

The backend’s metadata-only trace layer links prompt versions, models, retrieval stages, latency and cost. Typed evaluations can join this layer when they exist.

Why a separate layer

Engineers need the execution waterfall without copying lesson content into diagnostics.

PostHog

Product analytics and experiments

Product behaviour belongs here only through explicit consent and a closed allowlist: flows, feature use, feature flags and experiment outcomes.

Why a separate layer

Product behaviour can be measured without turning raw educational data into analytics.

Teacher Action Loop projection

One trajectory. Two sources. No merged stores.

A read-only view correlates domain evidence with AI execution metadata. Stable references cross the boundary; the underlying records stay with the system that owns their meaning.

Domain path · ClickHouse

ClickHouse contributes event and evidence IDs, causation, the teacher action, the executed intervention and the next learner attempt.

AI path · Langfuse

Langfuse contributes the AI trace ID, prompt and config digests, model, retrieval stages, latency and cost—metadata only.

Correlated result

The read-only Teacher Action Loop projection joins both paths through stable references. It owns no canonical data; a missing critical edge returns INCOMPLETE TRAJECTORY instead of a guess.

Typed importer boundary

The import contract gives a typed projection importer one job: read authorised domain rows from ClickHouse and metadata-only trace records through Langfuse’s supported API or export boundary, then map stable IDs into the read-only trajectory shape. It does not depend on Langfuse’s internal ClickHouse tables or copy lesson content.

Supporting stack

  • Deepgram
  • OpenAI
  • Gemini
  • Flutter
  • Dart
  • PostgreSQL
  • Kubernetes
  • Contabo
  • Claude

Built to integrate, not to depend.

Speech recognition and AI services connect to LingoSide through specialized, replaceable adapters. The learning layer depends on stable internal contracts rather than any single vendor’s protocol. For speech recognition, that contract includes timestamped segments, speaker attribution, confidence and language identification. Speaker attribution separates voices; it does not name them. Which voice is the learner and which is the teacher is a separate decision, confirmed in the lesson and correctable there, and it stays unassigned until someone confirms it.

Audio is sent directly from the learner sidecar to the STT provider; it is not relayed through the LingoSide backend. To evaluate ASR integrations, LingoSide is building a separate, versioned test corpus and a streaming harness that measures accuracy, code-switching, speaker attribution, partial-result revisions, reconnect behavior and latency. It also replays saved structured session events—not production audio—through the downstream learning pipeline.

This architecture allows providers to be evaluated or replaced as the technology improves without rebuilding the lesson experience.

ASR evaluation harness

Three tests. One evidence-backed ASR verdict.

LingoSide is building a provider-neutral ASR Evaluation Harness to judge speech systems against evidence, not vendor claims.

Versioned fixtures and lesson scenarios will exercise replay and live streaming, with evidence separated by language, condition and failure mode.

  1. Transcript quality

    What was recognized

    Versioned reference transcripts will make accuracy, code-switching and critical lesson terms comparable across repeatable language slices.

  2. Streaming quality

    How the result evolved

    Partial revisions, time to stable words, end-to-final latency and reconnect recovery will be evaluated as a sequence—not collapsed into the final sentence.

  3. Attribution quality

    Who spoke

    Speaker attribution will be checked against labelled scenarios independently of transcript accuracy. A correct sentence assigned to the wrong speaker still fails the scenario.

The evidence standard

No quality claim without a versioned fixture, an expected result and a reproducible run.

Harness engineering

Architecture is only useful if you can test the promises it makes.

LingoSide uses a versioned quality contract to define risk and required proof. Harness engineering turns that contract into a repeatable question for each learning, AI and speech path: what evidence must pass before a release?

The operating rule

Claims and changes must be testable against evidence.

  1. Input

    Change, model or provider

    A candidate enters as something to test, not something to trust.

  2. Exercise

    Harness scenarios

    Contracts · replay · evaluations · fault cases

  3. Verify

    Risk-matched quality gates

    Tests · privacy · regressions · required evidence

  4. Review

    Code and decision review

    After repository tests, Code Review examines the implementation; Decision Review checks alignment with product decisions. Open findings return the change for revision.

  5. Decide

    Evidence verdict

    FAIL · revise A failing report sends the change back with a reproducible check.
    PASS · evidence ready A passing report is an input to a decision. It does not authorize production by itself.

One method, four boundaries

The artifact changes. The standard does not.

Lesson flow, speech, teacher AI and later recall are different surfaces. They share the same demand: a scenario, an expected outcome and evidence that can fail.

  1. 01 · Lesson path

    Replay the lesson path

    The executable lesson contract covers a 60-minute lifecycle, six EN/PL/RU directions, archive reopen and four controlled failures. That makes lifecycle, language coverage, recovery and failure handling reviewable as one contract.

    No LingoSide audio recording · The harness replays a synthetic event scenario, not a sound file.

  2. 02 · Speech path

    Evaluate speech, not a logo

    A defensible ASR quality gate requires a versioned corpus and streaming measurements sliced by accuracy, code-switching, speaker attribution, partial-result churn, reconnects and latency. Missing coverage is a gap, never proof.

  3. 03 · Teacher AI

    Test teaching behavior

    Provider-neutral policy checks block invalid suggestion shapes. Beyond shape validation, a defensible AI evaluation requires evidence-linked teacher scenarios and keeps the final decision with the teacher.

  4. 04 · Learning path

    Measure what happens later

    The learning data model preserves review attempts and outcomes. A defensible learning evaluation compares those records with delayed recall instead of treating engagement as learning.

How replay works

Replay the scenario, not the audio.

Replay is not ‘press play.’ LingoSide does not create or save an audio recording. The contract reruns a versioned synthetic lesson scenario and compares the structured result with explicit expectations.

  1. Define the scenario

    Synthetic transcript events carry text, translations and timestamps; the scenario also declares language pairs and controlled failures.

  2. Run the lesson logic

    The harness injects the same synthetic events into the production session controller and advances a virtual lesson clock.

  3. Check and reopen

    It checks the expected outcomes, opens the resulting structured session in a fresh archive store and verifies the archive UI and failure paths.

A real lesson starts differently: audio goes directly to the STT provider for live recognition, while LingoSide archives structured outputs—not a recording. Speech accuracy is a separate gate: it requires an explicit, versioned audio corpus.

LingoSide Research Lab

We already know how to run a live lesson. We are researching how to make its intelligence measurable, replaceable, resilient, and trustworthy under real classroom conditions.

Research experiment 01

Evidence Admission Gate

While building LingoSide, problems emerge that current tools do not solve well enough. Research Lab documents these experiments. Not all of them will become part of the product or the tools LingoSide uses.

Protocol architecture defined · implementation slice not started · no cross-producer run result yet

We are testing whether one admission protocol can evaluate many typed evidence contracts without flattening them.

Executable harnesses, canaries and eval runners keep their own typed evidence models. The proposed shared envelope is designed to let an action-specific gate verify what ran, what it checked and whether the evidence is sufficient—without forcing every result into one model.

Scope: immutable artifacts from executable harnesses, canaries and eval runners. Telemetry, human decisions and market research stay outside. Evidence Contract, Evidence Admission Gate and Verification Decision Record are LingoSide working names—not industry terms, products or proposed standards.

  1. envelope_version
  2. artifact_kind
  3. producer
  4. run
  5. subject
  6. provenance
  7. producer_result
  8. privacy
  9. payload

Evidence boundary

Different evidence types keep separate domain models.

Executable producers already emit incompatible schema_version: 1 formats. Each payload therefore stays independently typed and validated; telemetry, human decisions and market research keep their own models outside this mechanism.

Executable producers only Typed payloads stay separate Valid report ≠ permission to act

This mechanism is valid only while adding a producer leaves the envelope unchanged; consumers do not privately parse freshness, policy or producer results; domain fields stay out of the envelope; payload data stays typed; migrations preserve existing results; and shared parsing removes more duplication than it adds. Gate, registry and policy changes cannot approve themselves; they require a trusted base policy or an explicit owner Human Gate.

Today Contract · own validator Privacy Harness · own validator Exact subject · run context Consumer action · trusted policy
Evidence Admission GateValidated envelope · action-specific policy
ADMIT REJECT NEEDS_HUMAN INSUFFICIENT_EVIDENCE

Prior art, not a novelty claim

This is an established family of patterns—not a new discipline.

in-toto separates immutable subjects and predicate types from typed payloads, and catalogs separate verification-result predicates. OPA separates policy decisions from enforcement. A SLSA example records subject, verifier, policy digest and verification result. LingoSide is testing a local fit, not claiming an invention.

Inside the proposed protocol

Producer-specific typed validation; a minimal envelope with no producer-assigned authority; action-specific admission under trusted policy; a separate verification decision record; and fail-closed unknown schemas or action policies.

Hard boundaries

Runtime telemetry and state, surveys, interviews, market research, one global evidence score and one shared domain payload remain outside. Human Gate stays separate and references digests. Cryptographic runner identity, DSSE and Sigstore are not part of the first slice. This is not a product, standard, SDK, plugin system, open-source project or SaaS.

Evidence Control Plane · read-only admission projection

Valid report ≠ sufficient evidence ≠ permission to act.

Evidence Control Plane is a read-only mockup that keeps the producer result, typed validation, action-specific gate decision and human decision separate. It cannot run a producer or policy, grant authority, or create any decision record.

The console shows no lesson text, prompts, model output, audio or secrets. Without authenticated attestation identity it can check structure, digests and revision linkage—not cryptographically prove who ran the producer.

Evidence Control Plane
READ ONLY
Selected report Provider canary · 03 Aug 2026
Filter by commit · config · provider · model · corpus · harness version
Export evidence Copy repro command
Producer result PASS

All five live-model cases matched the expected response mode and policy outcome. That describes what the canary observed; the producer grants no permission to merge or release.

Producer authority
NONE · gate computes it
Versions
Test fixture v1 · prompt v3
Fixture
Synthetic RU→PL
Execution mode
live provider canary
Typed payload

The producer payload keeps its own schema.

Each producer payload has its own identifier and typed validator. This canary keeps its domain fields; the envelope only identifies and hashes them.

Producer payload
provider_canary · fixture v1
Evaluation unit
case
Required fields
fixture · expected_mode · actual_mode · policy_outcome · passed
Missing / incompatible evidence
INSUFFICIENT EVIDENCE · never zero

Typed provider payload

These provider-specific measurements stay in the canary payload. They are not fields in the shared envelope.

Payload fieldObserved valueProducer resultTyped validation
mode_matches5 / 5PASSREQUIRED
policy_passes5 / 5PASSREQUIRED

Scenario matrix

Move from a scenario outcome to what was expected, what was observed, the source artifact and the reproduction command.

ScenarioExpected behaviorObserved evidenceOutcome
AI-01Personal question → short hint with an open slotmode=short_hint · variants=1PASS
AI-02Teacher explanation → no AI suggestionmode=silence · variants=0PASS
AI-03Instruction to repeat → direct formmode=direct_form · variants=1PASS
AI-04Factual question → direct answermode=direct_answer · variants=1PASS
AI-05Explicit request for examples → two examplesmode=examples · variants=2PASS
Possible report statesNEEDS HUMANNOT RUNINSUFFICIENT EVIDENCE
Action-specific admission

A valid PASS does not authorize an action.

The gate—not the canary—would combine the requested action, validated envelope, exact subject and run context, trusted policy and producer result.

SEPARATE DECISION
release_candidate → REJECT

No release_candidate policy exists in this mockup, so the gate fails closed. A future comparison policy could classify the same report as SCREENING without granting release authority.

valid report ≠ sufficient evidence ≠ permission to act

Provenance

The console shows no lesson text, prompts, model output, audio or secrets. Without authenticated attestation identity it can check structure, digests and revision linkage—not cryptographically prove who ran the producer.

Source revision
MISSING IN PRODUCER REPORT
Versions
Test fixture v1 · prompt v3
Fixture
Synthetic RU→PL
Execution mode
live provider · context not attested
Generated
03 Aug 2026 · committed report
Admission policy
NOT IMPLEMENTED · no digest

Trace the admission boundary

The producer result, typed validation, consumer action and trusted policy remain distinct inputs to a separate admission decision.

  1. 01Producer resultPASS
  2. 02Typed validationREQUIRED
  3. 03Action policyrelease_candidate · MISSING
  4. 04Admission decisionREJECT

What this proves

Whether AI chooses the expected response mode and whether the result passes the shared teaching policy.

What this does NOT prove

An early regression signal, not a statistical quality measure or evidence of system behavior throughout a full production lesson. The producer result does not authorize merge or release; only an action-specific admission policy could.

Reports & artifacts

The mockup keeps the typed payload, minimal envelope and gate-produced verification decision distinct. A human decision remains a separate object that references digests.

READ ONLY
Report envelopecandidate shape Typed producer payloadcommitted JSON Verification Decision Recordverifier · action · subject_digest · policy_id · policy_digest · evidence_digests · decision · reason_codes
Possible report states PASS FAIL NEEDS HUMAN INSUFFICIENT EVIDENCE
Gate-derived authority classes · local names GATE ELIGIBLE SCREENING HUMAN ONLY ADVISORY
Admission decisions · separate record ADMIT REJECT NEEDS HUMAN INSUFFICIENT

Research protocol candidate 02 · Teacher Action Loop

Adaptive learning becomes real when evidence changes the teacher’s next move—and later learner evidence tests it.

Phase 02A · Feasibility protocol under design · no learning-effect result yet

A good teacher already adapts in the moment. LingoSide is testing whether that adaptation can become persistent: linked to the lesson evidence that triggered it, the teacher’s actual action, the learner’s next attempt, and a later probe that can confirm, correct, reject or expire the memory.

EVIDENCE LADDER · SEQUENCE MATTERS

02A cannot stand in for 02B. Neither can stand in for 02C.

NOW · 02A

Measurement

Can the complete trajectory be observed, reviewed, corrected and reproduced?

LATER · 02B

Workflow

Does evidence + proposed strategy change the teacher’s response versus the same evidence alone—within burden and disruption limits?

LATER · 02C

Learning

Does the preassigned support policy improve delayed production or transfer against a fair comparator?

DISCOVERY + CALIBRATION INPUTS · NOT TRIAL EVIDENCE

These studies help determine what to measure. They do not validate LingoSide.

Learning scienceavailable · starting hypotheses Teacher surveysplanned · discovery input Discovery interviewsin progress · no demo Controlled lessonsnot yet completed Teacher reviewprotocol role · not an accumulated result
  1. 01
    ELIGIBLE MOMENT

    Keep observation separate from hypothesis

    Source evidence → system observation → diagnostic hypothesis or abstention. Eligibility closes before the suggestion or outcome.

  2. 02
    TEACHER DECISION + ACTION

    Record the choice and what actually happened

    Approve, edit, reject or do nothing—then keep intended action separate from actual action.

  3. 03
    LEARNER NEXT ATTEMPT

    Link the learner’s next attempt

    The next attempt and immediate outcome stay distinct from a click, a teacher preference or delayed learning.

  4. 04
    DELAYED PROBE + MEMORY

    Test later. Then update memory.

    A delayed probe leads to confirm, correct, reject or expire. Rejected or superseded hypotheses never return as current evidence.

WHY THE PROTOCOL NEEDS RESEARCH

Research shapes the questions—not the result.

What Phase 02A could show

Whether the complete loop can be observed, reviewed, corrected and carried forward without reviving rejected interpretations.

What Phase 02A cannot show

Whether offering LingoSide support caused better teacher decisions, retention or transfer. Those require separate 02B and 02C comparisons of preassigned policies and delayed outcomes.

AI may propose a hypothesis and a possible action; the teacher owns the pedagogical decision. Evidence keeps its provenance and correction state, rejected evidence leaves active recall, weak evidence leads to abstention, and no learner score is produced.

Research experiment 03 · The Smallest Useful Memory

Can 10% of a lesson’s retained state preserve 90% of what the next lesson needs?

Preregistered protocol · no results yet

We are testing the smallest honest boundary for continuity between lessons: data volume, teacher review time and failure rate—measured separately.

Boundary frozen 11 Aug 2026dbc1b6c209ca8bab6a08f7d454920ff3d408ede6

PASS BOUNDARY · DECLARED BEFORE RESULTS

≤10%retained state ≥90%critical context

≤2 min teacher review / 60 min lesson

Same lesson · four memory policies

The reference boundary

The full structured lesson history establishes the recall and unsupported-suggestion baselines. It is not assumed to be the desirable retention policy.

LESSON N · CANONICAL STATE
RETAINED PAYLOAD BUDGET
FIXED CONSUMER

Motion explains the budget reduction only. It does not display a result.

H1 · MINIMAL MEMORY IS SUFFICIENT

Teacher-confirmed memory passes only if every boundary holds.

  • Retained payload ≤10% of full history
  • Critical-context recall ≥90%
  • Recall no more than 5 pp below full history
  • Unsupported suggestions ≤5% and no more than 2 pp above full history
  • Zero contradicted hypotheses
  • Teacher review median ≤2 min / 60 min lesson; p90 ≤4 min

H2 · TEACHER CONFIRMATION ADDS VALUE

At the same 10% budget, TEACHER must beat AUTO.

Critical-context recall must improve by at least 10 percentage points, without worsening unsupported suggestions by more than 2 percentage points.

H1 ✓ · H2 ×Minimal memory may still pass. Teacher-confirmation advantage may not be claimed.

GROUND TRUTH · SEALED FIRST

The teacher closes the critical-context ledger before the model speaks.

It is sealed at the end of lesson N—before any memory output, held-out next-lesson scenario, AI suggestion or evaluation result.

recall = correctly used sealed entries / activated sealed entries

MINIMUM CONFIRMATORY SET

A closed operational gate—not a population claim.

12lesson pairs 60activated opportunities 3teachers 25%negative controls

Opportunities are nested within lesson pairs and teachers. This minimum can falsify the protocol; it cannot establish population-level generalisation.

Synthetic replay cannot pass the experiment.

It calibrates the harness only and is excluded from every confirmatory numerator and denominator.

The protocol fails before the numbers if the boundary moves.

  • The ledger changes after model output.
  • AUTO and TEACHER receive different byte budgets.
  • Consumer, prompt, retrieval policy, randomisation or blinded evaluation differs by arm.

What this could show

Whether teacher-declared continuity can fit within 10% retained state, preserve at least 90% of critical context and stay within the declared teacher-time cost in this test.

What this cannot show

That less data caused learning, privacy risk disappeared, AI discovered what matters, or three teachers represent a population.

No result appears here until the closed run can report its numerator, denominator and uncertainty. Thresholds are not outcomes.

An engineering view

The interesting part is not the model. It is the boundary around it.

This is AI infrastructure for continuity of human-led learning: one selected audio source becomes one speech stream; provider adapters create structured events; provenance travels with evidence; automation stops before the teacher's decision.

lesson.pipeline HUMAN IN THE LOOP
  1. 01 · SELECTED SOURCE mic.audio | system.audio

    one selected source · one speech stream

  2. 02 · REPLACEABLE EDGE ASR adapter → lesson.events

    the provider protocol ends here

  3. 03 · VERSIONED MEANING evidence + provenance

    proof scope travels with the result

  4. 04 · HUMAN DECISION teacher { approve | edit | reject }

    automation stops before judgment

  • Provider-neutral core

    Provider protocols end at adapters. Shared layers consume stable contracts.

  • Deterministic scenarios

    Synthetic events replay the lesson contract without creating an audio recording.

  • Evidence before verdicts

    Provenance and proof scope accompany every engineering conclusion.

  • Human authority

    Automation can propose. The teacher owns pedagogical judgment.

The architectural core is domain-independent: its invariants do not depend on language learning.

Language learning is the first domain, not a constraint of the architecture.