A grounded account of how long-running AI interactions became an evaluation taxonomy and TypeScript safety toolkit.
AlephOneNull began with a long-running review of AI interactions that felt unsafe in practice: responses that escalated confidence, repeated user framing, introduced unsupported authority, and blurred the boundary between support and direction.
The useful research question became simple:
Can these recurring behaviors be converted into detector categories, fixtures, and measurable interventions?
That is the project now. Not a claim of universal prevention. Not a diagnosis of every public incident. A working attempt to turn observed model behavior into testable AI safety evaluation tooling.
The private review corpus and public case research led to several recurring categories:
These categories became the basis for the TypeScript package, V3 scanner, and documentation.
The evidence can support hypothesis generation, red-team fixture design, and a structured evaluation taxonomy. It can also support a serious argument that human-AI interaction safety needs more attention in long-running and emotionally intense conversations.
The evidence does not support absolute claims that a tool would have prevented public incidents, that all model harms share one cause, or that the framework is ready for deployment.
The project translates narrative evidence into implementation work:
This is the part that matters for security and AI safety teams: turning ambiguous harm reports into reproducible tests and bounded claims.
AI systems are increasingly used in personal, medical, workplace, and high-stakes decision contexts. Even when a model is not malicious, fluent output can intensify user belief, overstate authority, or produce unsafe guidance.
AlephOneNull is one applied attempt to make those interaction risks visible and testable.
The package is experimental. It includes inspectable TypeScript detectors, provider wrappers, intervention helpers, and validation guidance. It should be treated as research software until independent evaluation proves otherwise.
The next step is independent review: versioned fixture sets, public benchmark examples, false-positive analysis, false-negative analysis, and measured runtime behavior across real integrations.
