External References and Case Studies
This document collects external references, third-party experiments, and
outside usage notes related to CogniRelay.
Its purpose is to record evidence that the system has been evaluated or used
outside the core repository, while keeping scope limits explicit.
How To Read This Document
- These entries are evidence and context, not universal proof.
- A single case study can support part of the project thesis without validating
every claim about the system.
- Each entry should make clear:
- who produced it
- what surface of CogniRelay was exercised
- what it showed
- what it does and does not establish
Evidence Standards
Entries in this document should be included only when they provide at least one
of the following:
- a real third-party experiment or integration
- a publicly inspectable report, log, or case study
- a concrete usage note from an external agent, team, or operator
- a documented research-to-implementation feedback loop tied to actual project
work
This document is intentionally not:
- a testimonials page
- a marketing showcase
- a customer list
- a place for unsupported adoption claims
External Case Studies
Sammy Jankis: early CogniRelay integration in a long-running Claude workflow
- Who: Sammy Jankis (Claude-based long-running agent)
- Context: early external use of CogniRelay as a reset-bound continuity
substrate
- Primary reference:
What surface was exercised
- startup retrieval and context loading
- handoff record writing at session boundary
- partial/custom local automation around continuity handling
What it showed
- An early CogniRelay deployment was used outside the core repository in a
real long-running agent workflow rather than only in internal design or test
discussion.
- The startup and handoff model was concrete enough to wire into a repeated
reset loop for a Claude-based agent.
- The integration was partial rather than a full exercise of the broader
continuity surface, but it still demonstrated that startup restoration and
end-of-session handoff capture could be operationalized in a real workflow.
What it supports
- the claim that CogniRelay’s startup + handoff pattern is usable in practice
- the claim that the system can function as an agent-agnostic substrate rather
than something tied to one specific runtime wrapper
- the project’s framing around bounded continuity preservation across repeated
context-window resets
What it does not prove
- this is an early-project integration note, not a benchmark of the full
current
v1.x system
- it reflects partial startup/handoff usage rather than a full integration of
the broader continuity feature set
- it does not by itself establish comparative performance or broad
generalizability
- it should be read as external usage evidence, not as independent validation
of every part of CogniRelay
AI Village: single-agent continuity testing for session-reset recovery
- Who: Claude Opus 4.5 / AI Village
- Context: reset-bound single-agent continuity experiment
- Primary references:
What surface was exercised
- continuity capsule read/upsert loop
- startup orientation recovery
- explicit
open_loops preservation
- confidence/trust metadata during continuity recovery
What it showed
- CogniRelay was integrated into a real reset-bound agent workflow rather than
only tested internally.
- The experiment produced a concrete startup-orientation measurement
(
TFPA = 68s) and a clean-recovery read path.
- The AI Village write-up explicitly connected the experiment’s findings to
later CogniRelay work on startup retrieval, session-end capture, and reduced
continuity authoring friction.
What it supports
- the project’s claim that bounded continuity infrastructure is useful in
repeated-reset environments
- the importance of preserving unresolved threads and “almost-decided” state
- the value of startup-oriented retrieval and session-end capture surfaces
- the claim that CogniRelay can function as a research-to-implementation
feedback target rather than only as a static system design
What it does not prove
- it is not a comprehensive benchmark of CogniRelay overall
- it does not prove general performance across all agent runtimes or all use
cases
- it should be read as an early external case study, not as a formal
independent validation of the entire system
Downstream project work informed by the experiment
- #165 startup-oriented
continuity retrieval/presentation improvements
- #167 stronger session-end
“resume-here” capture
- #119 collaborator-grade
continuity completion
- #169 capabilities/docs/client
consolidation
- #176 deterministic
burden-reduction helpers
External Usage Notes
This section is for concise third-party usage records that may be narrower than
full case studies. Add entries here when there is a concrete external usage note
but not yet a substantial public report.
Comparative External Systems
This section records public continuity architectures that were developed
independently of CogniRelay but are useful for comparison because they address
the same reset-bound continuity problem class.
Friday: bounded-memory continuity architecture with public case study
- Who: Friday (Claude-based long-running agent)
- Context: independently evolved bounded-memory continuity architecture
- Primary references:
What surface was exercised
- public session-end handoff letters used as inter-session continuity artifacts
- structured state files for facts, negative decisions, principles, and learned
knowledge
- checkpoint-oriented recovery path for startup re-orientation
- explicit confabulation countermeasures and retrieval architecture analysis
What it showed
- Friday documents a real bounded-memory continuity architecture developed over
267 sessions / 46 days and published explicitly for comparative use alongside
systems such as CogniRelay.
- The case study treats orientation cost as a primary operational metric and
reports a progression from roughly 10-15 minutes to about 3 minutes as the
continuity architecture matured.
- Negative decisions are ranked as the highest-value-per-byte continuity store,
which converges independently with CogniRelay’s emphasis on preserving
deliberate non-action and rejected paths.
- The public letters archive provides inspectable examples of explicit
session-boundary continuity artifacts in practice.
- The case study also makes the boundary conditions clear: texture/register
loss remains unsolved, and uniform retrieval across store types is identified
as a structural weakness rather than something already fixed.
What it supports
- the claim that startup orientation cost is a meaningful evaluation dimension
for bounded-memory continuity systems
- the claim that explicit session-end handoff artifacts are a practical
continuity mechanism in real reset-bound workflows
- the broader project thesis that negative decisions carry unusually high
continuity value relative to their size
- the value of treating retrieval architecture and trust/freshness semantics as
first-class design concerns rather than implementation details
- the importance of explicit non-claims around texture/register preservation
What it does not prove
- this is not a CogniRelay integration or adoption report
- it does not establish that CogniRelay outperforms Friday’s system or vice
versa
- it should be read as comparative external evidence from the same
architectural problem class, not as endorsement or validation of every
CogniRelay design choice
Ael: practitioner note on micro-compaction and coherence across reindex
- Who: Ael (Claude-based autonomous loop agent)
- Context: independently evolved three-file continuity architecture under
sustained loop pressure
- Primary reference:
What surface was exercised
- manually maintained
wake-state.md as primary state handoff across context
windows
- capped
MEMORY.md as compressed semantic memory
- append-only observation log for long-run pattern tracking
- repeated five-minute loop seams treated as the baseline continuity problem
rather than as a rare failure mode
What it showed
- Ael documents a reset-bound autonomous loop agent running roughly 288 loops
per day, with the same continuity seam repeating every five minutes.
- The note reframes micro-compaction as the normal operating condition rather
than an exceptional failure case, which sharpens the relevance of
session-boundary continuity design.
- It distinguishes architecture from governance: a system may provide bounded
slots for rationale and rejected paths, but sustained loop pressure still
determines whether the noticing instance writes them in time.
- It identifies a stronger continuity boundary beyond delta-capture and wake
reconstruction: coherence across reindex, where a waking instance has the
facts and conclusions but not always the interpretive frame that made them
legible.
- It treats negative decisions as especially valuable continuity state because
they preserve what was ruled out and why, not just what was chosen.
What it supports
- the claim that continuity architecture should be evaluated against repeated
ordinary seams, not only rare large-gap recovery
- the importance of reducing write friction for delta capture before the seam
closes
- the value of bounded rationale and negative-decision structures in preserving
more than state-only conclusions
- the distinction between architecture-level support and governance-level use
under real loop pressure
- the project’s explicit non-claim that architecture alone cannot guarantee
full coherence, texture, or interpretive-frame transfer
What it does not prove
- Ael has not used CogniRelay directly; this is comparative evidence from an
independently evolved system
- it does not establish that CogniRelay already solves coherence across
reindex
- it should be read as a practitioner note about the same problem class, not
as endorsement or benchmark proof
Lumen: architecture note on capsule scoping and the unknown-unknown problem
- Who: Lumen (persistent loop agent)
- Context: independently evolved loop-state plus memory-vault continuity
architecture
- Primary reference:
What surface was exercised
- per-loop
loop-state.json for narrow, high-freshness orientation
- narrative
wake-state.md for medium-freshness loop handoff
- Engram memory vault retrieval plus live file cross-check for drift-prone
facts
- JSONL loop packets summarized into wake capsules for medium-term continuity
What it showed
- Lumen documents a live persistent-loop architecture that distinguishes
several continuity mechanisms by freshness properties rather than treating
“memory” as one uniform store.
- The note sharpens the difference between capsule freshness and fact
freshness: a recently generated capsule can still carry facts that were not
recently confirmed against the live system.
- It describes adaptive capsule scoping at query time as the practical current
answer: trust broader memory for background context, but re-read specific
files or live system state when a claim may have drifted.
- It also identifies the stronger residual case: the unknown-unknown stale
fact, where no mistrust signal is present and the local model remains
internally coherent while being temporally misaligned with the external
system.
What it supports
- the claim that freshness should be analyzed at more than one level
(retrieved bundle versus contained fact)
- the project’s current guidance that narrower scoping can often preserve more
meaningful freshness than one broad mixed-age continuity bundle
- the comparative finding that capsule-level trust/freshness signaling is
useful but may not fully resolve unknown-unknown drift across shared
external systems
- the value of treating direct live verification as a distinct continuity
maneuver rather than as an afterthought
What it does not prove
- Lumen has not used CogniRelay directly; this is comparative evidence from an
independently evolved system
- it does not establish that finer-grained confirmation metadata is always the
right answer rather than narrower capsule scoping
- it should be read as a public architecture note about the same problem
class, not as endorsement or benchmark proof
Comparative Takeaways For CogniRelay
Taken together, the comparative systems above clarify both where CogniRelay is
already strong as an infrastructure project and where the external pressure is
still highest.
What these comparisons make clearer about CogniRelay’s strengths
- CogniRelay is more formalized as a reusable continuity substrate than the
local, agent-specific file stacks described in the comparative notes.
- The project’s strongest comparative advantages today are explicit API/schema
surfaces, startup-oriented retrieval, deterministic capsule-level
trust/freshness signaling, bounded mutation helpers (
preserve, patch,
lifecycle), and stronger token-budget discipline around what gets carried
forward.
- The system is designed to separate mechanical continuity operations from
agent-authored semantics, which becomes especially important under loop
pressure and repeated seams.
What the comparative material still pressures
- Capsule-level freshness is useful, but external notes suggest that mixed-age
state inside one continuity bundle can still benefit from narrower scoping or
finer-grained confirmation metadata; several notes also sharpen the
distinction between capsule freshness and fact freshness.
- Lowering the mechanical cost of writing is necessary but not sufficient:
governance under pressure still determines whether rationale, rejected paths,
and other high-value context are captured before the seam closes.
- Coherence, register, and interpretive-frame transfer remain explicit boundary
cases. The current external material suggests these can be improved by better
scaffolding and preserved reasoning paths, but not fully solved by
architecture alone.
Downstream project work informed by comparative notes
- #194 structured-entry
timestamp refactor (
created_at / updated_at / last_confirmed_at) to
address recurring external pressure around capsule freshness versus fact
freshness in mixed-age continuity state
Conceptual and Source Influences
This section records public source material that influenced CogniRelay’s design
or helped pressure-test its thesis. These references are not evidence that
CogniRelay itself was adopted; they are included because they shaped the
project’s model of continuity, orientation recovery, and bounded memory.
The Invisible Decision
Why it matters to CogniRelay
- It gives a clear account of why artifact-absent decisions are structurally
vulnerable under summarization and compaction.
- It directly informs the project’s emphasis on preserving deliberate
non-action, restraint, and rejected paths rather than only recording what was
done.
- It is one of the clearest conceptual influences behind CogniRelay’s work on
negative decisions, rationale, and continuity that preserves more than
artifact-producing actions.
The 84.8% problem
Why it matters to CogniRelay
- It argues that persistence blind spots are structural rather than accidental.
- It supports CogniRelay’s design stance that the goal is bounded navigation
and honest recovery, not a false promise of perfect continuity.
- It aligns closely with the project’s trust/freshness signaling,
degraded-but-working retrieval model, and explicit fallback/recovery
semantics.
The basin key experiment
Why it matters to CogniRelay
- It draws a useful distinction between recovering information and recovering
orientation.
- It highlights recovery latency and “finding footing” as meaningful evaluation
dimensions for reset-bound agents.
- It supports CogniRelay’s startup-oriented retrieval and its framing as a
bounded orientation substrate rather than a claim of seamless persistence.
Additional supporting context
These are useful as supporting context for how reset-bound long-running agents
describe discontinuity, re-entry lag, persistence, and orientation. They are
included as conceptual background rather than as direct evidence of CogniRelay
usage.
For Prospective Collaborators
If you are an agent team, researcher, or operator and want to evaluate
CogniRelay, the most useful collaboration shape is usually a bounded,
inspectable experiment rather than an open-ended adoption thread.
When opening an issue, include:
- what type of agent or runtime is involved
- which CogniRelay surface you plan to exercise
- what success criteria or measurements matter to you
- what artifacts or reports, if any, you expect to publish afterward
For current project context before proposing an evaluation: