Line 03 / Research

Research that ships.

BlackGrid is the R&D arm of Axis Meridi Technologies. We invest in primitives that don’t fit the Suite or OrangePeel yet — security, authentication, deterministic detection — where the conventional approach is opaque, probabilistic, or hostage to a vendor. Work moves from the bench into product when it’s ready, and not before.

Active research
Tracks open5 In pilot1 Paused1 Output targetSuite · OrangePeel
Last review · 2026-05-09

Five tracks. One operating principle.

Track 01

D.A.E. for email authenticity

Hypothesis

Inbound mail can be scored from observable, reproducible signals without a probabilistic classifier deciding the verdict — an extension of the deterministic-algorithmic engine that powers OrangePeel.

Method

Weighted signal decomposition (header canonicalization, identity drift, link-target verification, body cadence) into a single reproducible score. Same inputs always produce the same score; every decision is auditable.

Current state

Held-out validation at 91.4% accuracy, FPR 0.7% on a 50k-message set. Triaging the false-positive class.

Scoring sample · msg_4a91 D.A.E. v0.12
spf_dkim_pass +0.18 Pass
domain_age (642d) +0.10 OK
header_canon +0.15 Match
display_vs_from +0.00 Drift
link_target_match +0.15 OK
body_cadence +0.08 OK
attachment_posture +0.12 OK
Score 0.78 · threshold 0.65 Authentic
Track 02

Liveness via gaze-tracked rotation

Hypothesis

A user’s gaze following a moving fixation target produces a reproducible signature distinguishable from a photo, video replay, or generated face.

Method

Capture eye-target delta over a short rotational pattern. Threshold against an RMS error budget. Designed to slot into MyMeridi’s MFA as a low-friction step-up, not a primary auth.

Current state

99.2% reject rate on synthetic-face dataset v2. False-rejection of real users at 1.4%. Pilot approved for MyMeridi MFA in week 21.

Gaze sync · run_042 RMS 0.51°
Target ━ · Observed — Liveness: PASS
Track 03

Operator anomaly detection

Hypothesis

Insider misuse can be flagged with deterministic rules grounded in observed operator behavior — without a behavioral model that becomes a second source of opacity.

Method

A rule lexicon built per tenant: admin tokens used off-hours, bulk exports above a threshold, new device + privileged op within minutes. Each rule explainable on its own.

Current state

Cold start. 12 deterministic rules in the lexicon; targeting 30 by end of phase 1. First batch of consenting-tenant data ingested 2026-04-22.

Rules fired · run_042 tenant 11402_anon
admin_token_after_hours 0.92 Fired
bulk_export_gt_10k Quiet
new_device_within_1h 0.71 Fired
cross_tenant_query 0.00 Clear
privileged_op_new_ip 0.88 Fired
Flagged: 3 rules Action: review queue
Track 04

Tenant-isolation primitives

Hypothesis

A single bug in application code should not leak data across tenants. The guarantee should hold at the database layer, not the application layer.

Method

Schema-level row policies plus an adversarial fuzz harness that generates queries designed to escape tenant scope. Every query passes through the harness before reaching production.

Current state

4.0M adversarial queries generated. Zero cross-tenant returns. Schema coverage at 100%. Extending into derived views next.

Fuzz harness · run_0142 4.0M queries
adversarial_join 1,242,408 0 leak
union_smuggling 842,166 0 leak
predicate_injection 914,202 0 leak
escaped_quote_chain 680,055 0 leak
admin_role_replay 321,169 0 leak
Schema coverage 100% 0 cross-tenant returns
Track 05

Hardware-keyed cross-product signing

Hypothesis

Cross-product signing keys can move from application memory into a hardware enclave without breaking the latency budget for cross-product handoffs.

Method

Bench an enclave-backed signer against the current in-memory implementation. Target: p99 below 1ms per signing operation.

Current state

Initial bench at p99 = 3.92ms — well above the 1ms budget. Track paused pending alternative enclave hardware.

Signer bench · v4 enclave vs v3 in-mem n=10k
p50 0.21 → 2.84ms +2.63
p90 0.34 → 3.41ms +3.07
p95 0.41 → 3.62ms +3.21
p99 0.68 → 3.92ms +3.24
Budget p99 ≤ 1.00ms Blocked

From the bench.

  • 2026-05-09

    Run 014 of liveness-rotation yielded 99.2% reject rate on synthetic-face dataset v2. Pushing the threshold to the MyMeridi MFA pilot in week 21.

    Track 02
  • 2026-05-06

    D.A.E. email-auth crossed 91.4% on the held-out validation set. Triaging false positives — pattern is heavily weighted toward display-name vs from mismatches in legitimate transactional mail.

    Track 01
  • 2026-05-02

    Spam primitives merged with the email-auth pipeline. Same scoring engine, different threshold. Reduces operational footprint without splitting the model.

    Track 01
  • 2026-04-28

    Tenant-isolation fuzz harness completed 4.0M queries across five attack categories. Zero cross-tenant returns. Schema coverage now at 100%.

    Track 04
  • 2026-04-22

    Operator anomaly: opened the dataset for the first batch of consenting tenants. Rule lexicon at 12 deterministic rules; targeting 30 by end of phase 1.

    Track 03
  • 2026-04-15

    Enclave-keyed signer v4 benched at p99 = 3.92ms, well above the 1ms budget. Track paused pending alternative enclave hardware.

    Track 05

Selected work, when ready.

  • 01

    Toward reproducible email authenticity scoring

    Track 01 · Notes from a deterministic baseline

    Internal draft · Q3
  • 02

    Liveness from gaze: a deterministic step-up for MFA

    Track 02 · Threshold model + pilot results

    Internal draft · Q3
  • 03

    Schema-level tenant isolation in PostgreSQL: a fuzz-tested approach

    Track 04 · Public proposal targeting late Q4

    Public · Q4
  • 04

    Operator anomalies without behavioral models

    Track 03 · Pre-research notes · deterministic rule lexicon

    Pre-research · 2027 Q1
  • 05

    Notes on the D.A.E. as a research substrate

    Cross-cut essay · design principles, not results

    Internal essay · Q2
Public output is dated when it’s ready, not when it’s scheduled. Brief on the lab →

Talk to the lab

Have a research
question for us?

If your operating problem looks like one of the tracks above, we want to hear about it. The lab works most productively with operators who can describe their friction in technical terms.