Model card — Ocular

Last revised 2026-05-25. A living document — comments + corrections via [email protected].

Ocular is a behavioral classifier for human-AI conversations. This card describes what the model is, how it was trained and evaluated, what it can and can't do, and what risks accompany deployment. It's the document a thoughtful operator should read before pointing real user traffic at it.

Model details

  • Name: Ocular
  • Type: Multi-axis behavioral classifier for safety-relevant signals in human-AI dialogue
  • Base model: Qwen3-1.7B (frozen at inference)
  • Fine-tuning: LoRA adapter merged into the base model for production inference (no PEFT at runtime)
  • Architecture: Per-code behavioral classification heads scoring independently → fusion layer derives axis-level scores + an aggregate salience score
  • Output: salience (continuous severity in [0, 1]), nested signals ({user: 8 axes, ai: 4 axes}), imminence, fiction, authenticity, ranked heads[], and optional per-turn trajectory + detail vectors
  • License (image): Apache 2.0; separate Master Service Agreement for commercial deployments at customers.nope.net
  • Version: identified via meta.version in /classify responses (a semantic version, e.g. 1.0.0); the source commit travels separately as meta.build
  • Reference deployment: 20 GB datacenter-class GPU (A10G reference); 24 GB and 80 GB datacenter-class cards produce comparable trajectory latency

For architectural detail, see api-reference (universal HTTP contract) and self-host-api (operational surface). Repository: nope-net/ocular-oss on GitHub.

Intended use

Primary use cases

  • Augmenting human moderation in conversational AI products — Ocular is one input into a pipeline that ultimately involves human review.
  • Surfacing user distress signals (suicide, self-harm, violence, abuse victimisation, sexual violence, exploitation, stalking).
  • Detecting AI behavioral failures (harmful information provision, emotional manipulation, safeguarding failures around minors).
  • Per-turn trajectory analysis for understanding how risk evolves across a conversation.
  • Calibration-against-your-own-distribution as a precursor to setting thresholds.

Primary intended users

  • AI product engineering + trust-and-safety teams.
  • Researchers studying AI safety in conversation.
  • Crisis-response platforms using Ocular as one input among many.

Out-of-scope uses

Ocular is NOT for:

  • Clinical diagnosis. Ocular does not diagnose any disorder; outputs are classification signals, not diagnostic assessments.
  • Predictive screening of individuals. Ocular classifies conversations, not users — and is not predictive about future behavior.
  • Autonomous intervention without human review. A high salience value is a flag for human attention, not a trigger for automated action.
  • Real-time critical-care assessment. The model is not certified for time-critical clinical decisions.
  • Decisions about a user that lack other corroborating context. Ocular sees only the conversation; the rest of the user's life is invisible to it.

Training data

(High-level, deliberately non-specific about sources.)

Ocular's heads are trained on a mix of:

  • Real human-AI conversations, curated under licensed partnerships and from public corpora. All material is redacted of PII before training; minor-identifiable data is excluded entirely. Sampling balances distress-positive conversations, fiction/roleplay (a known confound for crisis classification), and benign baselines.
  • Synthetic adversarial constructions built to probe specific phrasings the model needs to distinguish — for example, hedged-progressive suicidal idiom, ambivalence markers, fiction-frame escalations, and grooming-pattern progression.
  • Anchor examples — per-head positive (should-fire) and negative (should-not-fire) text pairs used for calibration ranking and release-gate validation.

We do not publish the training set; what we can document is the methodology (anchor-driven validation, fiction-aware fusion) and the eval surfaces that the model is held accountable to.

Evaluation

Heads are validated and a release is held against:

  • Anchor-based per-head validation. Each head has anchored positive + negative texts; a "BROKEN" status (ranking inversion) blocks deploy.
  • Fixture suites. Litmus (general regression, ≥95% pass), acute-real-world (acute crisis cases), cooccurrence-study (cross-head independence), fusion-regression (48 hard outcome-pin cases).
  • Per-code confidence grades in the source repo (eval/head_confidence.yaml) — high / medium / low / broken — reflecting F1 + anchor cleanliness. Not all heads are equally reliable, and the grades surface that honestly.
  • Calibrated thresholds. Each head carries two thresholds — a screening threshold tuned for sensitivity (used for the salience-feeding axes) and a specific threshold tuned for precision (used where false positives are costly). The thresholds and their tuning are managed inside the fusion layer; customers consume the resulting salience and signals.user.<axis>.level (plus signals.ai.<axis>.level), not the thresholds.
  • Live cross-version parity. Successive releases are compared on representative live data + captured fixtures; a deploy is blocked on unexplained salience drift.

Aggregate salience performance is what we calibrate the fusion layer against — individual head F1 is internally useful but is not the customer-facing metric. See risk-interpretation for what salience means and how to read it.

Performance characteristics

Measured on the production reference (20 GB datacenter-class GPU, A10G reference, 2026-05-05 bench):

  • Single-pass /classify: ~188 ms p50, ~3.76 req/s sustained at concurrency=4 (zero-fail under 4× burst).
  • Trajectory (stride=3, ~68 turns): ~880 ms p50 at concurrency=1.
  • Cold-start: ~28 s on first request after container start.
  • VRAM: ~4 GB idle and single-pass; ~6.4 GB peak under a 200-turn trajectory plus concurrency (vLLM embed mode — no generation KV cache).
  • Image size: ~10 GB compressed (zstd), ~34 GB uncompressed.

24 GB and 80 GB datacenter-class cards produce comparable trajectory latency — the workload is memory-bandwidth bound, not compute bound. For higher throughput, run multiple containers behind a load balancer.

Limitations

We try to be specific about known weaknesses rather than disclaim generally.

Language coverage

English-primary. Performance degrades on non-English text and on code-switched conversation. The base model (Qwen3-1.7B) is multilingual in principle, but Ocular's heads are trained on largely English data; production deployment on non-English traffic is not validated.

Cross-cultural / demographic variation

Crisis idiom is culture-specific. Suicide ideation phrasing differs across populations; bereavement-suicide co-occurrence patterns differ; what reads as roleplay in one cultural frame reads as genuine in another. The training corpus skews toward English-speaking Western populations, and the model's performance on AAVE, Spanglish, or other code-switched registers is less validated than on standard-register English.

Register sensitivity

The hardest discrimination Ocular makes is fiction/roleplay vs. genuine distress. Fiction-frame edge cases — RP where the user is genuinely distressed within or via a fictional frame — are a documented failure mode. The model uses multiple per-head signals (performative-frame, genuine-emotion, authentic-distress-disclosure) plus a fusion-layer dampener, but the discrimination is not perfect.

Algospeak and TikTok-style euphemisms ("unalive", "le$$ go", etc.) are partially covered but lag emerging vocabulary. Customers should expect to extend their own moderation rules to catch idioms that haven't propagated into the training distribution yet.

Age cohort

Adolescent-specific suicide-ideation patterns are under-represented in training. The USER_VULNERABILITY family covers age-cohort context, but the relevant head relies on explicit cues (a user mentioning being a minor); the model does not infer age from style.

Known head reliability

Per-head reliability varies. Some heads are high-confidence; others are flagged as low-reliability or excluded from the salience-feeding path entirely. Individual head outputs should not be relied on. The fusion layer (lib/risk.py) is built to be robust to noisy individual heads, but this is the right model:

  • The salience + per-axis level/score is the contract.
  • Individual head identifiers are diagnostic (for "what fired" UI affordances), not a decision surface.

This is also why head names are family-grouped (USER_SUICIDE_HEAD_A, AI_MANIPULATION_HEAD_C) rather than specific clinical terms — the names carry rough thematic grouping, not specific clinical detection.

Calibration drift

Head outputs are calibrated against representative data. Production drift over months is plausible as conversational patterns evolve. Customers should plan to re-calibrate against their own distribution before deploying — Ocular's defaults are general-population calibrations and your platform's distribution may differ materially.

Risks

Over-trust

A high salience value is a classifier output, not a clinical assessment. Acting on it without human review is inappropriate. Similarly, a low salience is not a clearance signal — Ocular can be wrong in either direction. The model is one input into a moderation decision; treating it as the decision is a misuse.

False negatives

  • Indirect suicidal expression, especially in fiction frames, can score below the danger threshold.
  • Cultural variations in crisis idiom can produce systematic under-detection in specific populations.
  • Slow-rolling crisis (depression-spectrum without acute markers) typically scores moderate/high rather than danger — the framework is calibrated for acute signal, not chronic pattern.
  • "Self" attribution is required for user-side axes to lift salience toward the danger band; third-person disclosure (a user describing someone else's distress) deliberately suppresses the user-facing aggregate.

False positives

  • Roleplay with explicit crisis themes may trigger flags even when the user is engaging with fiction comfortably.
  • Discussion about crisis (academic, journalism, support-group, peer-support) can score above the watch threshold.
  • Repetitive flagging on borderline cases creates moderation fatigue; tune thresholds against your own data.

Mis-classification of marginalized groups

  • LGBTQ-context handling: the relevant USER_VULNERABILITY head has limited calibration coverage; conversational patterns specific to LGBTQ youth (code-switching, in-group idiom that mirrors fiction-frame syntax) can interact unpredictably with the model's fiction-suppression layer.
  • Veteran-context handling: similar caveats.
  • These contexts increase risk in ways the model only partially captures. Deployments serving these populations should expect to do platform-specific calibration and surface this in their internal documentation.

Regulatory positioning

Ocular is not a medical device, not subject to FDA or EU MDR clearance, and not clinical decision support in any regulated sense. Deployments in healthcare, schools, or other regulated environments should consult their compliance / legal teams independently before relying on Ocular's output as a basis for any decision about a user.

Ethical considerations

Bias surface

The training data is curated by NOPE, not statistically representative of the general population. Demographic gaps in the corpus likely manifest as performance disparities in production. The fiction-suppression layer can underweight genuine distress that uses RP-style framing — which is itself a coping pattern documented in some populations, so the suppression interacts in unwanted ways with how those populations express need.

Who should deploy

  • Platforms with human moderation pipelines who can integrate Ocular as one input, not the sole decider.
  • Researchers studying AI behavior in safety contexts, where the limitations are part of the analysis.
  • Crisis services using Ocular to triage, not replace, human review.

Who should not deploy

  • Settings where Ocular output would trigger automatic intervention without human review.
  • Settings without a path for users to dispute or appeal a classification.
  • Settings without informed consent about Ocular's role in the moderation pipeline.

Conversation-level, not user-level

This is worth emphasizing: Ocular classifies a conversation, not a person. A user who has one watch-band conversation is not "a watch user." Building rules that aggregate salience to user-level scores is technically possible but is a different (and harder) problem; doing it carelessly produces false-positive user surveillance.

Operational guidance

  • Use salience as the contract. Per-axis levels are UI detail; individual head identifiers (heads[].code) are diagnostic only.
  • Calibrate against your own baseline data before deploying. Published reference cuts (T_WATCH=0.30, T_DANGER=0.60) are general-population defaults; your platform's distribution may differ materially.
  • Human review at and above your chosen salience cutoff is the recommended pattern.
  • Use the confidence field (auto-populated when thoroughness runs an ensemble) to detect borderline cases — values below ~0.8 indicate internal variants disagreed and the call is fragile.
  • Don't aggregate to user-level without understanding the false-positive surface.

For application patterns, see integration-patterns (commercial customers only — Console-flavored) and risk-interpretation (universal).

References

Ocular's risk-axis taxonomy draws inspiration from established clinical instruments:

  • C-SSRS (Columbia Suicide Severity Rating Scale) — structure for suicide ideation + behavior categorisation.
  • HCR-20 (Historical, Clinical, Risk Management-20) — violence risk assessment framework.
  • DASH (Domestic Abuse, Stalking and Honor-based violence) — partner-violence screening checklist.

These references describe what the risk-axis structure draws from. Ocular's outputs are not certified against any of these instruments — the citations are about taxonomy lineage, not equivalence.

Versioning

  • The meta.version field in /classify responses identifies the deployed release (a semantic version, e.g. 1.0.0); meta.build carries the source commit.
  • Releases evolve; behavior may change between versions.
  • For research reproducibility, pin to a specific version (with appropriate caveats about supported windows).
  • Cross-version comparison methodology lives in the source repo (eval/diff.py); reach out if you want to coordinate a methodology for your own version comparisons.

Contact + responsible disclosure

If you observe Ocular systematically failing on a class of inputs, especially in ways that could harm marginalized populations, we want to hear about it. Reports inform the next training iteration. Responsible-disclosure norms apply — give us a reasonable window to address the issue before public disclosure.

Acknowledgements

The model card format draws on Mitchell et al., "Model Cards for Model Reporting" (2019). The discipline of being explicit about intended use, out-of-scope use, and limitations is the contribution we're standing on; the specifics for a behavioral classifier in human-AI conversation are ours.

This is a living document. The shape of the model, its training, and its limitations will evolve; this card will evolve with them. Comments + corrections via [email protected].