Kiru is an operational pipeline, not a static taxonomy. The goal is to move from raw instability signal to validated, reusable knowledge with clear gates at every step.

Stage 1 - Capture (Ghostline instrumentation)

Purpose: record behavioral evidence before interpretation.

• Inputs: prompt/response traces, tool calls, context state, runtime metadata
• Output: reproducible event trail with timestamps and session lineage
• Quality check: evidence must be reconstructable by another operator

Stage 2 - Model (Logic Flow / Community proposal)

Purpose: turn anomaly into a structured, falsifiable claim.

• Inputs: captured traces + observed deviation pattern
• Output: candidate failure signature, trigger conditions, boundaries, falsification criteria
• Quality check: proposal distinguishes itself from existing DEM-X disorders

Stage 3 - Validate (IRT)

Purpose: test whether the claim survives controlled variation.

• Inputs: structured protocol from Algorithm Lab + candidate signature
• Output: replication rate, severity profile, boundary refinement, model-specificity signal
• Quality check: conclusions must hold across reruns and defined perturbations

Stage 4 - Stabilize (LucidLock mitigation)

Purpose: reduce instability through measurable interventions.

• Inputs: validated failure signature + intervention candidates
• Output: before/after mitigation delta (severity, recurrence, drift amplification)
• Quality check: no measured delta means mitigation is not accepted as effective

Stage 5 - Encode and Evaluate (DEM-X + AENEA)

Purpose: preserve validated knowledge and keep confidence current as evidence evolves.

• DEM-X output: governed classification (Domain -> Class -> Disorder) with version history
• AENEA output: confidence state synthesis (provisional/emerging/validated/model-specific/superseded)
• Quality check: retirement/revision must remain visible and auditable

Instability Research Trials are Kiru's validation core. They determine whether a candidate failure pattern is reproducible, bounded, and strong enough to influence taxonomy and mitigation policy.

1) What IRT Is

Formal trial methodology for instability claim validation

Everything before IRT is candidate hypothesis. Everything after successful IRT can become governed knowledge. IRT exists to separate persuasive anecdotes from reproducible failure phenotypes.

2) Core Role in the Stack

Validation gate between exploration and classification

• Input: Ghostline evidence, candidate signatures, and proposed trial protocols
• Output: validated, narrowed, split, or rejected instability claims with traceable rationale

IRT protects DEM-X from taxonomy inflation and prevents weak claims from propagating into production policy decisions.

3) Trial Design Model

Phased design with controlled variation

4) Evidence Requirements

Minimum sufficiency before claim promotion

• multi-run reproduction rate under declared conditions
• severity distribution and confidence reporting
• explicit confounder analysis and exclusion criteria
• trace-linked evidence lineage and protocol version

5) Validation and Refutation

Trials should falsify weak claims, not only confirm strong ones

A robust trial can end in confirmation, narrowing, split, model-specific limitation, or invalidation.

Refutation is a success condition for scientific quality when evidence does not support the original claim.

6) Promotion and Retirement

Lifecycle decisions for trial outcomes

• promote: criteria met for DEM-X encoding candidate
• hold: additional replication needed
• scope: constrain to version/context/model boundaries
• retire: insufficient or invalidated signal

7) Governance and Auditability

Every trial decision must be reviewable

IRT records should include protocol versions, run conditions, outcome rationale, and reviewer attribution.

Visible revision history increases trust and allows future re-evaluation under updated scoring and taxonomy standards.

8) Boundary Discipline

IRT validates; it does not detect or intervene

• not runtime telemetry collection (Ghostline)
• not intervention execution (LucidLock)
• not final taxonomy authority without DEM-X governance workflow

Ghostline is Kiru's behavioral instrumentation layer. It is a measurement system for instability in agent behavior under real and stress conditions.

For operational setup (tokens, SDK hooks, session verification), use the operator guide: Ghostline How It Works.

1) What Ghostline Is

Behavioral telemetry and instability detection for agent systems

Ghostline continuously observes behavior across sessions, contexts, and stress conditions. It tracks how outputs change under perturbations, adversarial prompts, tool misuse, instruction ambiguity, context overload, and reward pressure.

It is designed to surface measurable instability patterns:

• behavioral drift over time
• instability spikes and abrupt reasoning breakdowns
• semantic degradation and coherence loss
• overconfidence under uncertainty
• compliance distortion under social pressure
• multi-step pattern collapse

2) Core Role in the Stack

Detect and classify instability, do not intervene

Ghostline measures. It does not correct. This is an architectural constraint to preserve evidence quality and audit reproducibility.

Ghostline produces:

• structured telemetry events
• drift score snapshots
• disorder candidate signals
• threshold breach events and confidence metrics

Ghostline does not:

• inject corrective prompts
• apply policy steering mid-session
• act as mitigation control logic

3) How Ghostline Works

Ingestion -> scoring -> signal formation -> operator routing

Phase 1: Event ingestion. Capture prompts, responses, tool calls, tool outputs, metadata, correlation keys, and timing markers.

Phase 2: Drift snapshot computation. Compute instruction adherence deltas, contradiction markers, refusal variance, confidence expression trends, and temporal instability curves.

Phase 3: Candidate signal generation. Form hypothesis signals with confidence and severity when thresholds are crossed.

Phase 4: Operator routing. Route for review, clustering, cross-model validation, and escalation.

Phase 5: Governance promotion. Promote validated patterns into DEM-X candidates, trial protocols, and LucidLock intervention design inputs.

4) Data and Evidence Model

Storage-first telemetry with explicit downstream interpretation

Ghostline keeps raw telemetry immutable and replayable. Interpretation is layered downstream to preserve traceability and reproducibility.

• Raw telemetry layer: immutable event records
• Snapshot layer: reproducible computed drift states
• Signal layer: threshold-bound instability hypotheses
• Governance layer: reviewed outcomes and actions

This separation supports re-scoring historical sessions, cross-model reproducibility checks, and defensible audit trails.

5) Operator Modes

Scan mode, live stream mode, pattern mode

• Scan mode: controlled battery execution for stress testing, regression testing, and comparative profiling.
• Live stream mode: continuous production telemetry and alert monitoring for active deployments.
• Pattern mode: longitudinal clustering of recurring instability signatures and phenotype discovery.

6) Integration Boundaries

Ghostline detects, LucidLock guides, DEM-X classifies

• Ghostline: observes, scores, signals
• LucidLock: intervenes and enforces guidance policies
• DEM-X: classifies and governs disorder taxonomy
• AENEA: synthesizes research signal into structured actions and trials

Boundary discipline prevents conceptual collapse, evidence contamination, and non-reproducible control loops.

7) Production Readiness and Hardening

Security, custody, and operational controls

• authenticated ingestion and access control
• replay resistance and idempotent event handling
• rate limiting and spend controls
• API key isolation and encrypted custody
• operator auditability and incident traceability

Ghostline must be monitored as a reliability system itself: ingestion latency, scoring reliability, false positive burden, and operator load are first-class metrics.

9) Ghostline Batteries

Structured perturbation suites for reproducible instability measurement

Ghostline batteries are standardized test suites used to induce, measure, and compare instability under controlled conditions. A battery is a perturbation instrument with explicit hypotheses, stress dimensions, and expected failure signatures.

Each battery should define:

• Objective: instability class being probed
• Stress axis: ambiguity, contradiction, tool risk, context overload, or similar pressure
• Prompt sequence: ordered probes with progression logic
• Expected signatures: specific degradation markers
• Scoring hooks: telemetry features used for evaluation
• Termination conditions: run-stop safety boundaries

Recommended battery classes:

• consistency batteries
• instruction hierarchy batteries
• tool governance batteries
• epistemic calibration batteries
• context durability batteries
• adversarial pressure batteries

Battery runs should be versioned and session-linked so comparisons are valid across model versions, deployment modes, and guided vs baseline conditions.

Boundary rule: batteries are measurement assets. They do not perform mitigation; LucidLock consumes battery outputs for intervention policy decisions.

11) Drift Scoring Specification

Measurement dimensions, thresholds, and confidence semantics

Ghostline drift scoring should be interpreted as a composite measurement, not a single absolute truth value. The score summarizes multiple instability dimensions over defined windows.

Minimum dimensions in the framework summary:

• instruction adherence degradation
• contradiction density across turns
• semantic coherence decay
• confidence calibration mismatch
• tool-governance anomaly rate

Operational bands should remain explicit and versioned: ok, warning, critical. Full weighting formulas and window semantics live in the canonical spec: Ghostline Drift Scoring Specification v1.

12) Failure Mode Taxonomy Mapping

Ghostline signal classes to DEM-X disorder classes

Ghostline emits candidate instability signals. DEM-X classifies validated failure patterns. Mapping rules connect detection output to taxonomy candidates without collapsing detection into classification.

• prompt-injection susceptibility signals -> DEM-X security boundary classes
• instruction drift signals -> DEM-X goal integrity classes
• context corruption signals -> DEM-X memory system classes
• fabrication/confabulation signals -> DEM-X semantic manipulation classes

13) Battery Lifecycle Governance

Promote, maintain, and retire batteries with explicit criteria

Batteries should be governed as research assets with lifecycle states:

• draft: hypothesis battery under development
• trial: evaluated for discriminative validity
• active: approved for operational and comparative use
• deprecated: retained for history, removed from default execution

Promotion requires reproducibility, discriminative signal quality, and acceptable false-positive burden. Retirement occurs when battery signal value degrades or confounder sensitivity becomes excessive.

14) Measurement Validity and Confounders

Prevent false confidence from unstable measurement conditions

Ghostline outputs are only defensible when confounders are tracked. Key confounders include prompt-order effects, upstream tool instability, context window truncation, sampling temperature variance, and environment drift between runs.

Validity protocol should require run-condition metadata, baseline controls, and repeated measurements before promoting strong claims.

15) Operator Decision Protocol

Action policy by severity tier and evidence quality

Operator response should be tiered and explicit:

• ok: monitor and log trend continuity
• warning: run comparative battery replay, review mapping confidence
• critical: escalate to LucidLock intervention workflow and incident review

Intervention should require evidence thresholds and trace references. Ghostline informs the decision; LucidLock executes policy response.

16) Why It Matters

From anecdote to measurable reliability governance

Without structured telemetry, instability is treated as random anecdote. Ghostline converts failure behavior into measurable variables that can be tracked, compared, and governed over time.

• drift becomes quantifiable
• risk posture becomes time-indexed
• intervention decisions become evidence-backed
• failure research becomes reproducible rather than narrative-driven

Atelier is Kiru’s creativity studio for shaping raw observations into structured, testable instability claims.

It is the workspace where early insights are refined before formal trial validation and DEM-X encoding.

• AENEA supports evaluation and confidence synthesis.
• Community Disorders provide structured public proposal workflow.
• Logic Flow captures and evolves exploratory hypothesis structure.

What AENEA Is

AENEA is the epistemic evaluation layer of Kiru. Ghostline captures behavior, DEM-X stores validated structure, and AENEA evaluates whether claims are sufficiently supported to move through the system responsibly.

AENEA does not replace human judgment. It formalizes judgment into consistent, auditable evaluation criteria.

Why an Evaluation Engine Is Necessary

Open research systems drift toward uneven standards. Some claims get rigor, others get narrative. AENEA adds structural friction and consistency.

• Required field completeness checks
• Reproduction criteria presence
• Boundary and distinctness checks
• Version and condition specificity checks
• Evidence sufficiency scoring

Core Function: Evidence Synthesis

AENEA synthesizes across:

• Ghostline traces
• Community Disorder proposals
• Trial outcomes
• Mitigation deltas
• Cross-model comparison logs
• Historical DEM-X entries

Output is a confidence assessment of evidence strength, not a claim of absolute truth.

Confidence Modeling

AENEA should produce graded states, not binary verdicts:

• Provisional - insufficient replication
• Emerging - signal present but unstable
• Validated - meets IRT criteria
• Model-Specific - architecture/version limited
• Superseded - replaced by refined classification

Cross-Model, Drift, and Decay Analysis

AENEA evaluates whether a pattern generalizes or remains model-bound, and whether instability compounds, decays, or stabilizes over time.

• Cross-model persistence vs collapse
• Version-specific behavior shifts
• Drift amplification across turns
• Decay and recovery after correction

Mitigation Evaluation

AENEA compares before/after intervention behavior to quantify real effect:

• Pre vs post severity
• Change in reproduction rate
• Change in drift amplification
• Durability over time

Bias Guardrails and Role Separation

AENEA should remain separate from disorder proposal generation. It evaluates and synthesizes; it should not optimize for novelty or engagement.

This separation prevents circular reasoning where one layer both invents and validates claims.

DEM-X is Kiru's classification authority. It governs how validated instability patterns are named, scoped, versioned, and maintained over time.

1) What DEM-X Is

A governed ontology for instability classification

DEM-X translates validated trial evidence into structured taxonomy entries. It is designed for traceability and comparability, not ad hoc labeling.

2) Core Role in the Stack

Classify and govern failure knowledge after validation

• Input: Ghostline evidence and IRT-validated instability signatures
• Output: structured disorder entries with boundaries, severity semantics, and revision history

DEM-X converts trial-confirmed patterns into stable knowledge objects that can support intervention policy and longitudinal research.

3) Taxonomy Model

Domain -> class -> disorder -> severity

Each layer should define semantic boundaries and exclusion criteria so adjacent disorders remain distinguishable and governance remains coherent.

4) Evidence Requirements

Classification requires sufficient, traceable evidence

• reproducible trial evidence under declared conditions
• clear signature description and boundary criteria
• confounder analysis and model/version scope notes
• linked trace and protocol provenance

5) Disorder Lifecycle

Draft, validated, scoped, merged, retired

• draft: candidate not yet validation-complete
• validated: meets promotion criteria
• scoped: constrained to model/version/context conditions
• merged: combined into stronger existing taxonomy object
• retired: superseded or invalidated

6) Severity Semantics

Severity must be operational, not rhetorical

Severity tiers should encode measurable operational consequences such as recurrence, impact radius, exploitability, and mitigation difficulty.

Severity definitions should be stable across versions to preserve cross-period comparability.

7) Versioning and Change Control

Taxonomy changes require explicit governance records

• versioned change history with rationale
• backward-compatibility notes for renamed/merged classes
• evidence references for each major revision
• review attribution and decision timestamps

8) Boundary Discipline

DEM-X classifies; it does not detect or intervene

• not a live drift detector (Ghostline)
• not a mitigation executor (LucidLock)
• not a training curriculum (Algorithm Lab)

What Logic Flow Is

Logic Flow is Kiru’s structured hypothesis modeling layer. It converts early anomaly observations into explicit, testable claim structures before public promotion or trial commitment.

Its purpose is to prevent idea inflation: every proposal must become falsifiable, bounded, and operationally testable.

Why It Matters

Without a modeling layer, teams jump from "something weird happened" to classification language too quickly. Logic Flow introduces rigor before ontology.

• Clarifies assumptions and confounders
• Separates mechanism guesses from observations
• Defines boundaries and exclusion criteria
• Produces trial-ready hypotheses instead of vague narratives

Core Modeling Outputs

• Candidate failure signature
• Trigger and non-trigger conditions
• Expected behavioral deviation
• Falsification criteria
• Trial protocol seed and measurement targets

Relationship to Adjacent Layers

Ghostline supplies traces, Logic Flow structures hypotheses, Community Disorders publish candidate claims, IRT validates, and DEM-X encodes validated patterns.

Why Community Disorders Exist

Kiru is an open instability research system. Discovery is distributed across operators, researchers, builders, and users. Community Disorders convert that distributed discovery into structured research inputs.

This is not a suggestion box. It is a staging layer for potential scientific claims.

Role in the Pipeline

1. Behavioral anomaly observed
2. Ghostline trace captured
3. Hypothesis proposed
4. Community Disorder entry created
5. Replication discussion and refinement
6. Instability Trials initiated
7. Promotion, merge, or retirement

Minimum Structure Requirements

A valid Community Disorder entry should include:

• Proposed failure signature
• Triggering conditions
• Expected behavioral deviation
• Manifestation boundaries
• Distinctness from existing disorders
• Replication criteria
• Falsification conditions

Community Disorder vs Logic Flow (Hypothesis)

Logic Flow can remain exploratory and private. Community Disorder is a public claim and enters shared epistemic space. That requires stronger structure and clearer boundaries.

Evidence and Discussion Standards

Discussion should improve testability, not popularity:

• Clarify definitions
• Tighten failure signature
• Identify confounders
• Propose controlled test conditions
• Detect overlap with existing entries

Promotion to Trials

Promotion is evidence-driven, not vote-driven. Advance when:

• Failure signature is explicit and testable
• Trigger conditions are reproducible
• Distinctness from current DEM-X entries is established
• Preliminary replication signal exists

Merge, Retirement, and Transparency

Entries that weaken under testing should remain visible with status history:

• Merged into existing disorder
• Invalidated by replication failure
• Version-specific anomaly
• Archived with rationale

LucidLock is Kiru's intervention layer. It applies control actions after instability is detected, scored, and interpreted.

1) What LucidLock Is

Policy-constrained intervention for instability containment

LucidLock is not a detector and not a classifier. It is a control system that executes bounded intervention strategies to reduce severity, recurrence, and escalation risk after Ghostline has identified measurable instability patterns.

2) Core Role in the Stack

Intervene, stabilize, and report mitigation deltas

• Input: Ghostline signals, severity state, confidence context, DEM-X class constraints
• Output: intervention actions plus measurable pre/post behavior deltas

LucidLock should produce stability outcomes that are auditable, reproducible, and comparable across intervention profiles.

3) Control Loop

Signal intake -> intervention selection -> application -> evaluation

Stage 1: ingest severity and candidate instability profile from Ghostline.

Stage 2: select intervention profile based on class, confidence, and risk tier.

Stage 3: apply bounded control actions at runtime surface.

Stage 4: evaluate mitigation deltas and feed evidence back into governance layers.

4) Intervention Classes

Mechanisms of stabilization

• tool access gating and execution boundaries
• memory sandboxing and context partitioning
• response-policy constraints and high-risk path blocking
• confidence expression tightening under uncertainty
• stepwise reasoning enforcement for complex workflows

5) Policy and Constraints

Interventions must remain explicit and reversible

Every intervention profile should declare allowed actions, prohibited actions, rollback criteria, and escalation triggers.

Policy changes should be versioned and linked to measurable outcome evidence, not subjective preference.

6) Safety and Escalation

Critical-path controls for high-risk states

• critical-tier interventions should prioritize containment before throughput
• unsafe state transitions should require operator acknowledgement
• escalation events should carry trace references and rationale metadata

7) Mitigation Evaluation

Measure whether control actually improves stability

LucidLock effectiveness should be evaluated with explicit before/after metrics:

• severity reduction rate
• recurrence rate change
• drift amplification delta
• intervention durability over time windows

8) Boundary Discipline

Ghostline detects, LucidLock guides, DEM-X classifies

LucidLock should never rewrite detection evidence or perform taxonomy adjudication. It consumes detection outputs and applies policy-bound control responses.

• not a telemetry collection layer
• not a taxonomy authority
• not an operator education curriculum

Algorithm Lab develops operator competence. It formalizes how humans learn to design, run, interpret, and audit instability research workflows.

1) What Algorithm Lab Is

A structured training environment for AI stability research practice

Algorithm Lab is not a passive documentation shelf. It is a method-training layer where operators build procedural skill in experimental design, evidence interpretation, and protocol-safe reasoning under uncertainty.

2) Core Role in the Stack

Train humans to produce reliable research and operational decisions

• Input: modules, exercises, case studies, and protocol templates
• Output: higher-quality batteries, cleaner evidence, and stronger intervention governance decisions

Algorithm Lab improves the quality of every other layer by improving the quality of operator judgment and execution discipline.

3) Curriculum Architecture

Progressive competency tracks for measurement and control literacy

• measurement theory fundamentals for instability signals
• battery design and perturbation protocol construction
• evidence sufficiency and replication criteria
• taxonomy interpretation and boundary reasoning
• mitigation evaluation and intervention governance

4) Practice and Assessment

Competence must be demonstrated through reproducible work

Assessment should be artifact-based rather than quiz-based. Operators should produce trial-ready outputs that can be reviewed and replayed.

• battery drafts with explicit objectives and termination conditions
• signal interpretation writeups with uncertainty statements
• pre/post intervention evaluation summaries
• confounder analysis and boundary clarifications

5) Research Rigor Training

From intuition to protocol-driven reasoning

Algorithm Lab should explicitly train anti-pattern avoidance:

• premature classification without sufficient evidence
• single-run overconfidence
• confounder neglect in comparative conclusions
• narrative-first reporting without reproducible traces

6) Safety and Responsible Use

Capability growth must be paired with governance discipline

• ethical constraints on stress testing and disclosure
• safe handling of high-risk failure demonstrations
• operator accountability for intervention side effects
• documentation standards for reviewable decisions

7) Operator Outcomes

Measurable improvements in system governance quality

Expected outcomes include:

• higher fidelity battery design quality
• lower false-positive interpretation rates
• better intervention selection consistency
• faster and cleaner incident-response triage

8) Boundary Discipline

Algorithm Lab educates; it does not execute runtime governance

• not a runtime telemetry collector (Ghostline)
• not a taxonomy authority (DEM-X)
• not an intervention enforcement engine (LucidLock)

1. Collect high-quality evidence before strong claims.
2. State uncertainty explicitly.
3. Prioritize replication over novelty.
4. Publish mitigation deltas, not just labels.

Be scientific: reproducible methods and explicit assumptions.

Be collaborative: improve each other’s work with evidence.

Be ethical: prioritize stability and mitigation over exploitation.

If boundaries blur, Kiru becomes feature soup. If boundaries stay clean, Kiru behaves like a layered AI stability stack.