Prototype of LIMEN Runtime Audit — feedback welcome

Research
1

Hi everyone,

I have just published the first public prototype of LIMEN Runtime Audit, a small open-source toolkit for inspecting layer-wise activation trajectories in open-weight language models.

GitHub repository:

This is my first public GitHub repository, so feedback on the code, methodology, terminology and documentation would be genuinely valuable.

What is the basic idea?

Most LLM evaluations focus on the final output:

  • Was the answer correct?
  • Did the model follow the instruction?
  • Was the output safe?
  • What was the probability or perplexity?

LIMEN adds another descriptive layer: it examines how the model’s hidden activation vector changes as information passes through successive layers.

For each token, the toolkit treats the sequence of hidden states across layers as a measurable trajectory.

The objective is not to claim that these trajectories directly represent reasoning, semantic concepts or cognitive states. The objective is to provide a reproducible observability layer for comparing internal runtime behaviour.

What can the current prototype do?

Version 0.1 accepts exported NumPy arrays with:

  • hidden_states: [tokens, layers, hidden_dim]
  • optional logits: [tokens, vocabulary]

It currently measures:

Metric Plain-language interpretation
Path length Total movement across layers
Displacement Direct distance between the first and final layer
Tortuosity How indirect the layer-wise route is
Mean speed Average change between adjacent layers
Speed variability How regularly or irregularly the representation changes
Mean acceleration How much the layer-to-layer movement itself changes
Turning angle How much the direction of movement changes
Entropy Uncertainty in the output distribution
Top-1/top-2 margin Separation between the two leading token probabilities

The toolkit also:

  • checks array dimensions and rejects non-finite values;
  • records extraction metadata;
  • calculates a SHA-256 checksum for the source trajectory;
  • generates machine-readable JSON;
  • produces a compact Markdown audit report;
  • runs automated tests on Python 3.10, 3.11 and 3.12.

What could this eventually be useful for?

With proper validation and controls, this kind of instrumentation could potentially help with:

  • comparing internal profiles across model architectures;
  • comparing checkpoints before and after fine-tuning;
  • detecting extraction-pipeline changes or corrupted trajectories;
  • identifying unusual runs relative to a reference distribution;
  • studying whether prompt families produce reproducible dynamic differences;
  • investigating behavioural regressions that output metrics alone may not explain;
  • building model-monitoring dashboards for open-weight systems;
  • testing whether internal trajectory features add predictive value beyond ordinary baselines such as entropy, probability margin, token position and response length.

These are possible applications, not validated product claims.

Important scientific boundary

This prototype is currently a descriptive audit and observability tool.

Its measurements do not, by themselves, establish:

  • functional localization;
  • semantic state identity;
  • reasoning;
  • consciousness;
  • causality;
  • controllability;
  • universal attractors;
  • prediction of answer quality.

A geometrical difference is an observation. Explaining what that difference means requires separate experiments, controls and held-out validation.

The next important milestone is therefore predictive validation: testing whether LIMEN trajectory features detect or predict held-out behavioural regressions beyond conventional baselines and shuffled controls.

Why publish it now?

The project grew from an independent empirical investigation of runtime activation dynamics. Earlier experiments used broader dynamical-systems terminology. As controls accumulated, I decided that the public engineering implementation should use narrower and more cautious language.

Instead of waiting for every research question to be resolved, I am releasing the minimal audit layer so that other people can inspect it, challenge it and potentially reproduce or improve it.

Feedback I would particularly appreciate

  1. Are the current metrics defined clearly enough?
  2. Which existing interpretability or observability libraries should this integrate with?
  3. Which open models and datasets would make the strongest validation panel?
  4. What baselines or negative controls are missing?
  5. Would checkpoint comparison, fine-tuning regression analysis or runtime anomaly detection be the most useful first application?
  6. Is the terminology understandable to people who do not normally work with geometric or dynamical-system concepts?
  7. What would you require before considering this useful in a real model-audit workflow?

The repository is released under the Apache 2.0 licence.

GitHub:

Thanks in advance for any critical feedback, failed reproductions, issues or pull requests. At this stage, a rigorous objection is more useful to me than enthusiastic agreement.

2

For now, I tried it out a little in Colab:

My current answer would be:

The most useful first application looks like extraction/provenance regression and controlled checkpoint or training-drift instrumentation. Fine-tuning regression analysis would be the strongest next research step. I would place general runtime anomaly detection later, after testing benign environment shifts, unseen fault classes, calibration stability, and false-positive behavior.

The current terminology is mostly understandable, especially because the repository already separates geometrical observations from semantic or causal interpretations. I would only define “trajectory” once, very explicitly, as:

For one token, a trajectory is the ordered sequence of its hidden-state vectors across model depth.

For integration, I would use a plain Hugging Face Transformers forward pass as the canonical reference extractor, then add optional adapters for TransformerLens and NNsight. That keeps LIMEN’s input contract independent of any one interpretability framework.

A practical default route could be:

canonical extraction contract
    -> exact-repeat and corrupted-artifact fixtures
    -> controlled checkpoint/training-drift comparison
    -> independent-seed, checkpoint and prompt controls
    -> fine-tuning regression with real behavioral labels
    -> unknown-fault and benign-drift evaluation
    -> calibrated operational audit workflow

The main reason I would start there is that the small tests below found a reproducible coarse training-drift signal, including across held-out pre-training seeds. However, they also found an important boundary: using another seed’s final checkpoint as the reference worked almost as well as using the matched seed. That suggests the strongest raw signal may reflect a training-stage or activation-scale trend shared across runs, rather than a uniquely matched internal signature.

So I would currently describe the evidence as:

  • good support for reproducible extraction and artifact checks;
  • preliminary support for controlled checkpoint/training-drift measurement;
  • an interesting but incomplete cross-run signal;
  • no current support for a universal anomaly threshold, behavioral-quality prediction, fault severity, safety prediction, or causal localization.

Direct answers to the seven questions

Question My practical answer
Are the metrics clear enough? Mostly yes. Define trajectory as a depth-wise path, document degenerate cases, and distinguish absolute from norm-relative geometry.
Which libraries should it integrate with? Transformers first as the canonical extractor; TransformerLens and NNsight as adapters.
Which validation panel? Pythia/PolyPythias for controlled training dynamics, followed by another family such as SmolLM2 or OLMo and then a real fine-tuning regression.
Which baselines or controls are missing? Output metrics, activation norms, direct state distance, checkpoint metadata, wrong-reference controls, grouped holdouts, and complementary representation-similarity measures.
Best first application? Extraction/provenance regression and controlled training-drift instrumentation.
Is the terminology understandable? Yes, provided “trajectory” and “audit” are narrowly defined and do not imply time, cognition, causality, or a pass/fail verdict.
What is needed for a real workflow? A declared failure model, reference population, operating threshold, false-positive/false-negative reporting, benign-drift tests, provenance, ownership, privacy rules, and a response path.

I would also keep three possible products separate:

  1. Extraction/artifact audit: Did the extractor, tensor shape, ordering, dtype, revision, or serialized artifact change?
  2. Reference-relative comparison: How did a checkpoint or fine-tune differ from a declared reference under matched inputs?
  3. Standalone anomaly monitoring: Is the current run unusual without access to an exact matched reference?

The first is already close to a useful engineering tool. The second now has some preliminary evidence. The third requires a substantially different evaluation and calibration problem.

Cross-seed sanity check: PolyPythias-31M

I used six independent EleutherAI/pythia-31m-seed* runs from PolyPythias. The public PolyPythias resource adds nine seeds across five Pythia sizes and about 7,000 checkpoints, specifically to study stability under changes in initialization and training-data order or packing.

For each of six seeds, I used step143000 as a final reference and compared it with:

  • step142000
  • step128000
  • step64000
  • step16000
  • step1000

The Probe used 12 fixed short examples from arithmetic, factual, lexical and code families. It ran in FP32 on a T4 with eager attention and use_cache=False. Model revisions and the LIMEN revision were pinned, outputs were finite-checked, and raw hidden states were not included in the returned archive.

The prediction target was:

log1p(abs(143000 - checkpoint_step))

This is a transformed measure of checkpoint distance. It is not a quality, damage, safety, or behavioral-regression target.

Main held-out results

Evaluation Feature set Mean fold MAE Pooled Spearman rho
held-out seed LIMEN raw summary deltas 0.902 0.901
held-out seed direct matched state distance 0.946 0.908
held-out seed conventional output deltas 1.418 0.734
held-out seed dummy mean 1.617 —
seed and checkpoint both held out LIMEN raw summary deltas 1.493 0.795
seed and checkpoint both held out LIMEN relative deltas 1.470 0.629
seed and checkpoint both held out direct matched state distance 1.562 0.824
seed and checkpoint both held out conventional output deltas 1.853 0.420
seed and checkpoint both held out dummy mean 2.021 —

The raw trajectory-summary deltas therefore retained a fairly strong coarse ordering on an entirely held-out pre-training seed. Some signal also survived when both the seed and checkpoint identity were held out.

A target-shuffle control for the seed-held-out branch produced MAEs around the dummy level and rank correlation near zero, while the actual LIMEN and direct-state results remained substantially better.

Important wrong-reference result

I also compared each run with another seed’s final checkpoint instead of its own final checkpoint.

Evaluation Matched-seed LIMEN MAE Wrong-seed LIMEN MAE Matched rho Wrong-seed rho
held-out seed 0.902 0.820 0.901 0.918
held-out checkpoint 1.375 1.470 0.845 0.832
seed and checkpoint both held out 1.493 1.469 0.795 0.817

This was the most informative control.

The result does not show that an exactly matched same-seed reference is necessary. A safer interpretation is that the raw LIMEN summaries are detecting a training-stage or activation-scale pattern broadly shared by these 31M runs. That is potentially useful for cross-run instrumentation, but it is different from detecting a seed-specific anomaly signature.

This is also compatible with the PolyPythias paper’s broader finding that many learning dynamics are consistent across seeds, while some runs still become outliers.

Where the result weakened

The pooled rank statistic hides poor calibration near the final checkpoint.

For the raw LIMEN model under checkpoint holdout:

  • holding out step142000 gave an MAE of about 2.79;
  • holding out step128000 gave an MAE of about 2.08;
  • the much earlier checkpoints were predicted considerably better.

So the current signal looks more useful for distinguishing broad early/middle/late training stages than for measuring subtle unseen drift near convergence.

Other boundaries:

  • The same 12 prompts appeared on both sides of the seed and checkpoint splits, so this did not test unseen content.
  • Direct hidden-state distance was similarly competitive.
  • Several raw metrics are sensitive to residual-stream scale.
  • path_length and mean_speed are algebraically redundant when the number of layer transitions is fixed.
  • Only one model size, six seeds and five non-reference checkpoints were used.
  • No portable scalar threshold emerged.

My takeaway is that this strengthens training-drift instrumentation as a first research direction, while also making the next controls clearer:

  • include activation or residual norm directly;
  • include validation loss and checkpoint metadata when available;
  • rotate or average several wrong-seed references;
  • test unreferenced current-checkpoint features;
  • jointly hold out seed, checkpoint and prompt family;
  • replace checkpoint age with a real sample-level behavioral target.
Matched checkpoint sanity check: Pythia-70M and Pythia-160M

I also ran a smaller matched-reference check on Pythia-70M and Pythia-160M. Pythia is particularly convenient here because the suite releases 154 checkpoints per model and was designed for research on learning dynamics.

The setup used:

  • reference checkpoint: step143000;
  • comparison checkpoints: step142000, step128000, step64000, step1000;
  • 16 short samples across arithmetic, factual, lexical and code families;
  • four grouped folds, each holding out one complete prompt family;
  • FP32, eager attention, use_cache=False;
  • a full-sequence forward pass for hidden-state extraction;
  • exact pinned revisions;
  • target shuffles and layer-order shuffles.

Held-out prompt-family results

Model Feature group MAE Pooled Spearman rho
70M matched LIMEN summary deltas 0.503 0.943
70M conventional output deltas 0.569 0.893
70M output + LIMEN 0.506 0.884
70M dummy 1.654 —
160M matched LIMEN summary deltas 0.576 0.948
160M conventional output deltas 0.525 0.893
160M output + LIMEN 0.372 0.934
160M dummy 1.654 —

The trajectory-summary deltas tracked checkpoint distance across the held-out prompt families in both sizes. All archived non-dummy results beat all 100 target-shuffle repetitions in this small panel.

The combined feature set clearly improved calibrated error for 160M, but not for 70M. I would therefore describe incremental value beyond output metrics as model-dependent and preliminary, rather than as a reproduced general result.

A layer-order shuffle also substantially changed the metric-delta structure. This supports the narrower statement that the measurements depend on true layer adjacency. It does not prove that the natural order is functionally or causally privileged.

Important limitations:

  • Only four checkpoint-distance levels were present.
  • Checkpoint identity and training run were not held out.
  • Every useful feature depended on a matched reference.
  • Checkpoint age was the target, not behavior.
  • High rank correlation is relatively coarse with four ordered levels.
  • Several raw metrics shared almost identical rankings because of scale sensitivity and mathematical dependence.

This Probe and the PolyPythias Probe are complementary:

  • this one held out prompt families but not seeds or checkpoint identities;
  • the PolyPythias one held out seeds and checkpoint identities but not prompt content.

They should not be combined into a claim of simultaneous unseen-content, unseen-seed and unseen-checkpoint generalization.

Deterministic mutation checks on Qwen2.5-0.5B and 1.5B

I also used deterministic forward-hook mutations on Qwen2.5-0.5B-Instruct and Qwen2.5-1.5B-Instruct.

The interventions included:

  • residual attenuation;
  • block skip;
  • attention-output zeroing;
  • MLP-output zeroing;
  • early, middle and late locations.

These are best described as mutation tests. They are not natural runtime faults, incident reproductions, or safety failures.

The most important distinction was between reference-dependent and standalone features.

Reference-dependent comparison

Features containing direct matched hidden-state distances, such as state_delta_l2_*, produced near-perfect clean-versus-mutated separation.

That is useful evidence that the paired regression path is sensitive to known changes. However, because the clean reference is exactly zero-distance from itself while a mutation is generally nonzero-distance, this result should not be called standalone anomaly detection.

Current-run features without direct state subtraction

Evaluation 0.5B AUC 1.5B AUC
held-out prompt family 0.802 0.879
held-out fault type and prompt family 0.781 0.840
held-out fault location and prompt family 0.591 0.581
scalar-only, held-out location 0.749 0.723

The standalone ranking signal was therefore moderate, but fault-dependent. Unseen fault location was the weakest branch, and representation choice materially affected the result.

Severity prediction was negative on average for both sizes. Detecting that an intervention occurred did not imply that the features measured how damaging it was.

Cross-size experiments retained some ranking signal, roughly in the AUC 0.68–0.77 range, but the decision threshold did not transfer reliably. This again favors reporting rank transfer and calibration transfer separately.

One extraction lesson was also important: forcing the BF16-configured 1.5B checkpoint into FP16 on a T4 produced non-finite hidden states during a clean forward pass. The stable run used FP32 fallback and an all-layer finite-value preflight. That is a precision and extraction-contract issue, not a LIMEN result.

Overall, this branch suggests:

  • paired structural regression can be very sensitive;
  • standalone features may have some fault-dependent ranking value;
  • unseen-location transfer remains weak;
  • severity and portable thresholds are currently unsupported.
Metric definitions and terminology

I think the present metric table is generally readable. A few small clarifications would make it easier for non-specialists and reduce accidental overinterpretation.

1. Define the axis explicitly

“Trajectory” could be defined as:

the ordered path through layer outputs for a fixed token.

This is a path over model depth, not elapsed physical time, and it does not imply a cognitive or semantic process.

2. Declare the exact extraction points

The manifest should state:

  • whether the embedding output is included;
  • which residual or hidden-state output is selected;
  • whether the final state is before or after a final normalization;
  • the layer indexing convention;
  • whether the extraction came from model() or generate();
  • whether it represents prefill, decode, or a post-generation full forward pass.

This matters because the Transformers output contract may include the embedding output, and hidden_states[-1] does not necessarily equal last_hidden_state for every model.

3. Identify dependent metrics

For a fixed number of layer transitions:

mean_speed = path_length / number_of_transitions

They can still both be convenient report fields, but they are not independent evidence.

4. Specify degenerate cases

It would help to define what happens when:

  • displacement is zero;
  • every adjacent step is zero;
  • one of the two vectors used for a turning angle has zero norm;
  • tortuosity is undefined;
  • a machine-readable metric cannot be computed.

For strict JSON, an undefined value can be represented as null with an accompanying status or reason rather than a non-standard NaN.

5. Report absolute and relative geometry together

Raw Euclidean movement may capture useful information, but it can also be dominated by activation scale.

I would keep both:

  • absolute L2-based measurements;
  • source-norm-relative or otherwise normalized measurements;
  • direct activation-norm summaries.

If the raw measurement predicts something while the normalized measurement does not, that is itself a useful result—but it changes the interpretation.

6. Preserve ordered profiles

Global scalars are compact, but different mutations produced different advantages for scalar summaries versus ordered layer profiles.

A useful report could therefore contain:

  • global scalar summaries;
  • a depth-normalized ordered profile;
  • the layer or region where a deviation begins;
  • explicit wording that onset is not necessarily causal origin.

7. Be cautious across independently trained bases

Raw vector subtraction is natural for checkpoints that retain a shared coordinate system, especially within one training run.

Across independent seeds, separately trained models, or different architectures, representation bases may not be directly aligned. In those cases, LIMEN’s invariant summaries can be compared, but direct vector subtraction needs justification or an alignment method.

Complementary comparators could include:

  • layerwise cosine or L2 where coordinates are shared;
  • Procrustes-style alignment;
  • SVCCA;
  • CKA.

I would treat these as comparison tools with different invariances, not as universal gold standards.

Integration route and extraction contract

My preference would be extractor first, adapters second.

Canonical path: Hugging Face Transformers

A normal full-sequence forward pass is probably the simplest reference implementation:

outputs = model(
    input_ids=input_ids,
    attention_mask=attention_mask,
    output_hidden_states=True,
    use_cache=False,
    return_dict=True,
)

The extractor can then normalize the model-specific output into the LIMEN schema.

The manifest should preserve at least:

model id and immutable revision
tokenizer id and immutable revision
rendered prompt and token ids
chat-template revision or hash
attention mask
model() versus generate()
prefill/decode/post-generation-forward mode
cache setting
selected activation name
embedding inclusion
layer indices
token/logit alignment
dtype and actual parameter dtype
device and attention backend
library versions
normalization performed before LIMEN

Hub model and tokenizer artifacts should ideally be pinned to immutable revisions rather than a mutable branch; the Hub download documentation supports revision-specific loading.

TransformerLens adapter

TransformerLens is useful when a supported architecture benefits from canonical hook names, activation caching, residual-stream access, or interventions.

I would normalize TransformerLens activations into the same LIMEN manifest rather than making its internal naming system the LIMEN storage schema.

NNsight adapter

NNsight is useful for tracing arbitrary PyTorch models and capturing or modifying intermediate values.

Again, the adapter should name the traced module and extraction point explicitly, then emit the common LIMEN tensor and manifest format.

Evaluation connector

For predictive validation, LightEval or lm-evaluation-harness could supply reproducible output-side labels.

I would keep evaluation integration optional at first. The extraction contract and golden fixtures are useful even without a benchmark framework.

Golden fixtures

A small fixture pack could provide a high information-to-maintenance ratio:

  1. exact repeated extraction;
  2. altered tensor shape;
  3. non-finite activation;
  4. layer-order corruption;
  5. token/logit offset mismatch;
  6. one known checkpoint pair;
  7. expected strict JSON and checksum output.

This would make extraction-pipeline regression a concrete first use rather than only a future possibility.

Suggested validation decision tree

The next experiment depends on which product is being validated.

What is the immediate goal?
|
+-- Verify extraction or serialization
|   |
|   +-- pin model/tokenizer/code revisions
|   +-- run a canonical full forward pass
|   +-- validate shape, finiteness and token alignment
|   +-- compare against exact-repeat and known-corruption fixtures
|
+-- Compare checkpoints or a fine-tune
|   |
|   +-- use matched prompts and token positions
|   +-- report output-only, LIMEN-only and combined models
|   +-- include direct state distance and activation norm
|   +-- test same-run and wrong-reference comparisons
|   +-- hold out prompt family, checkpoint and run separately
|   +-- predict a real behavioral delta when possible
|
+-- Detect unknown runtime anomalies
|   |
|   +-- define the candidate failure classes
|   +-- include benign backend/dtype/library/model shifts
|   +-- hold out fault type, location, model and environment
|   +-- calibrate on a declared reference population
|   +-- report FPR, FNR, precision/recall and abstentions
|
+-- Use the result in an operational audit
    |
    +-- assign ownership and review responsibility
    +-- define data retention and access
    +-- define an alert investigation path
    +-- define rollback and re-calibration triggers
    +-- document known blind spots

A compact staged research panel

Stage 1: controlled same-run dynamics

Pythia remains a good starting point because its checkpoints and training setup are public.

Useful controls:

  • exact-repeat;
  • adjacent and distant checkpoints;
  • layer-order shuffle;
  • target shuffle;
  • direct state distance;
  • activation norm;
  • output entropy, margin and NLL;
  • checkpoint step and training loss where available.

Stage 2: independent-run stability

PolyPythias supports leave-one-seed-out tests.

Important reporting split:

  • ranking transfer;
  • threshold or calibration transfer;
  • per-seed outliers;
  • matched versus wrong references.

Stage 3: another model family

Possible open resources include:

The purpose would not be to pool all architectures into one universal score immediately. It would be to test whether the same descriptive report remains meaningful under a declared model-family adapter.

Stage 4: real post-training regression

A stronger target would be a known change in:

  • task correctness;
  • sample-level NLL;
  • instruction-following score;
  • forgetting;
  • robustness;
  • a clearly defined safety or refusal behavior.

The OLMo 2 1B Instruct model flow is interesting because intermediate RLVR checkpoints are publicly available.

The main question would become:

Do LIMEN features add held-out predictive value for a named behavioral change after ordinary output metrics, checkpoint metadata, activation norms and simple representation distances are included?

That seems closer to the milestone described in the original post.

Stage 5: natural anomaly monitoring

Only after the previous stages would I test:

  • real incident replays;
  • corrupted weights or artifacts;
  • tokenizer/template changes;
  • quantization changes;
  • backend and precision changes;
  • distribution shift;
  • unseen fault types and locations.

Synthetic hook mutations remain useful controls, but they should not be the only positive class.

Baselines and negative controls

I would group baselines by the question they answer.

Output-side baselines

These test whether internal measurements add anything beyond behavior already visible at the output:

  • target NLL or perplexity;
  • entropy;
  • top-1/top-2 margin;
  • task correctness;
  • generated length;
  • token position;
  • format or refusal indicators where relevant.

Always report:

  • output-only;
  • LIMEN-only;
  • output + LIMEN.

Direct representation baselines

When the coordinate system is shared:

  • layerwise L2;
  • layerwise cosine;
  • final-state distance;
  • average matched state distance;
  • layerwise activation norm.

These may be less interpretable as a compact “path,” but they are strong simple comparators.

Representation-similarity baselines

When comparing representation sets or independent runs:

  • CKA;
  • SVCCA or PWCCA;
  • Procrustes alignment;
  • representational similarity matrices.

Each method has different invariances and sample-size behavior, so agreement among methods is more informative than declaring one canonical answer.

Metadata baselines

For checkpoint-age experiments:

  • training step or token count;
  • learning rate;
  • training or validation loss;
  • model size;
  • layer count.

Checkpoint metadata cannot replace a runtime detector, but it helps reveal whether the experimental target is nearly tautological.

Negative controls

High-value controls include:

  • target permutation;
  • prompt-label permutation;
  • layer-order permutation;
  • wrong-seed or wrong-checkpoint reference;
  • unrelated model reference;
  • unchanged exact repeat;
  • benign dtype/backend/library change;
  • coordinate rotation or scaling where mathematically appropriate;
  • a comparator using only activation norm.

A layer shuffle only shows that true adjacency matters to the metric. It does not show that the metric predicts behavior.

A wrong reference that performs almost as well as the matched reference is not necessarily a failed experiment. It can reveal that the metric tracks a broader population-level trend rather than reference-specific identity.

What I would require for a real model-audit workflow

The word “audit” can cover several different levels, so I would declare which one is meant.

Level 1: artifact and provenance audit

Questions:

  • Was the expected model revision used?
  • Was the tokenizer/template unchanged?
  • Was the extraction point unchanged?
  • Are shapes, finite values and checksums valid?
  • Can the artifact be reproduced?

This can be largely deterministic.

Level 2: comparative model audit

Questions:

  • Did a checkpoint or fine-tune change relative to a declared reference?
  • Which prompts, tokens or depth regions changed?
  • Does the change survive normalizations and simple baselines?
  • Is the result stable across repeated extractions?

This is reference-relative and descriptive.

Level 3: statistical anomaly monitor

Questions:

  • What is the reference population?
  • What counts as benign variation?
  • What operating threshold is used?
  • What false-positive and false-negative rates were measured?
  • Does calibration transfer to new models, prompts, hardware and software?

This requires held-out data and periodic re-calibration.

Level 4: governance or safety audit

Questions:

  • Who investigates an alert?
  • Which action is allowed on the basis of the signal?
  • Is there human review or abstention?
  • What evidence is required before rollback or blocking?
  • How are raw activations, prompts and reports retained and protected?
  • What are the known blind spots?

LIMEN’s geometric measurements could be one evidence source in such a workflow, but the metric alone would not constitute the audit decision.

Before operational use, I would expect at least:

  1. a versioned extraction schema;
  2. immutable provenance;
  3. a documented reference population;
  4. separate raw and normalized metrics;
  5. simple output, norm and representation baselines;
  6. grouped and nested held-out evaluation;
  7. benign-shift controls;
  8. a declared threshold and abstention range;
  9. per-model or per-environment calibration unless portability is demonstrated;
  10. alert ownership and response procedures;
  11. privacy and retention rules for activation artifacts;
  12. explicit statements of what the score cannot establish.

Bottom line

My vote would be:

First engineering milestone: a canonical Transformers extractor, versioned manifest, golden fixtures, strict artifact validation, and a reference-relative comparison report.

First research milestone: controlled checkpoint/training-drift instrumentation across prompts and independent seeds, with output metrics, activation norms, direct state distance, wrong references and checkpoint metadata as mandatory comparators.

Next substantive milestone: predict a real held-out fine-tuning or behavioral regression, rather than checkpoint age, and show incremental value beyond those simpler baselines.

Later milestone: standalone unknown-anomaly monitoring with benign-shift controls and an explicit operating point.

The small Colab results make the checkpoint/training-drift branch look worth pursuing. At the same time, the wrong-seed control, weak near-final calibration, competitive direct-state baseline and negative severity results are useful guardrails against moving too quickly from “measurable internal difference” to “diagnosed model failure.”

That seems consistent with the repository’s current scientific boundary: LIMEN can become a useful reproducible observability layer without needing to assign semantic, causal, quality, or safety meaning to every geometric change.

3

hello cant read you message the systeme blocked if you can direct message it would be great , love your feedback