Forem: kodomonocch1

Why I stopped measuring AI workflow validation by replies and started measuring it by real payloads

kodomonocch1 — Sun, 29 Mar 2026 13:39:13 +0000

Most AI workflow demos still optimize for “looks structured.”

That is not the same as “won’t break downstream.”

A response can look clean, JSON-shaped, and convincing — and still be the exact thing that causes manual rework, routing mistakes, compliance issues, or downstream breakage.

That’s the gap I’m trying to pressure-test.

What I’m testing

I’m building a narrow evaluator surface for high-stakes AI workflows.

The terminal outcomes are intentionally constrained:

accepted
succeeded
failed_safe

The goal is simple:

Either return something safe to use, or fail safely with a classification and a trust artifact.

This is not a generic model wrapper.
It is not broad “AI automation.”
It is a narrow reliability layer for workflows where silent failure is expensive.

Public evaluator kit:

https://kodomonocch1.github.io/dlx-kernel/

Why I changed my mind

At first, it’s easy to measure interest by replies, comments, or general reactions.

But that’s not the real test.

The real test is whether someone is willing to submit an actual workflow payload where bad output has a real downstream cost.

That is a much better signal than opinions.

If a system claims to improve reliability, it should be tested against real failure-sensitive payloads — not only polished demos.

What I need now

I need 1 real payload from a workflow where silent failure is expensive.

Examples:

document extraction
invoice / AP automation
procurement workflows
ticket routing
compliance classification
any workflow where malformed structured output causes breakage or costly review work

Submit here:

https://kodomonocch1.github.io/dlx-kernel/submit-payload.html

What I need from you

one sample payload
one target schema
one short note on downstream risk

What I return

succeeded or failed_safe
failure classification
public-safe receipt / trust artifact
initial evaluator review within 24 hours

I’m not looking for broad onboarding, marketplace-style submissions, or generic support requests.

I’m looking for one real payload that is worth testing against.

If you have one, I’d really appreciate it.****

Searchable JSON compression: page-level random access + ms lookups (and smaller than Zstd on our dataset)

kodomonocch1 — Thu, 19 Feb 2026 19:12:38 +0000

Searchable JSON compression with page-level random access (and smaller than Zstd on our dataset)

Most JSON compression stories end at “make it smaller.”

But in real systems, the bigger cost is often decompress + parse + scan — repeatedly.

I built SEE (Semantic Entropy Encoding): a searchable compression format for JSON/NDJSON that keeps data queryable while compressed, with page-level random access.

On our dataset, SEE is smaller than Zstd and supports fast lookups (details + proof below).

Why this matters: the hidden “decompress+parse tax”

If you store NDJSON as zstd, most queries still pay:

read large chunks
decompress everything
parse JSON
scan for the field/value you need

Even if the data is small, the CPU + I/O pattern is brutal at scale.

SEE targets workloads where you repeatedly need:

exists / pos / eq-style queries
random access
low latency without full decompression

What SEE is (in 60 seconds)

SEE is a page-based, schema-aware format:

page-level layout for random access
Bloom + skip to avoid touching irrelevant pages (high skip rate)
schema-aware encoding (structure + deltas + dictionary where useful)
designed to reduce both:
- data tax (storage/egress)
- CPU tax (decompress/parse)

Trade-off: SEE optimizes for low I/O and low latency, not always absolute minimum size (though it can win on size too, depending on the dataset).

KPI snapshot (public demo)

These are the numbers we publish from the demo pack:

Combined size ratio: ≈ 19.5% of raw
Lookup latency (present): p50 ≈ 0.18 ms / p95 ≈ 0.28 ms / p99 ≈ 0.34 ms
Skip ratio: present ≈ 0.99 / absent ≈ 0.992
Bloom density: ≈ 0.30

“Combined” is the total footprint for the SEE artifact on the dataset we benchmarked.

Proof-first distribution (so you can verify without meetings)

I intentionally ship reproducible packs:

1) Demo ZIP (10 minutes)

prebuilt wheel + sample .see artifacts
demo scripts that print KPIs (ratio/skip/bloom/p50–p99)
OnePager PDF

2) DD Pack (audit / repro artifacts)

run summaries + run_metrics.json
verification checklist (pack_verify.txt)
designed for technical diligence

Recent robustness milestone: strict decode mismatch checks across multiple datasets = 0
(decode_mismatch_count=0, decode_extended_mismatch_count=0, audit PASS).

Quick start (demo)

pip install see_proto
python samples/quick_demo.py

This prints:

compression ratio
skip/bloom
lookup p50/p95/p99

What I’m looking for

SEE is not a SaaS product.
I’m exploring strategic acquisition or an exclusive license with teams that have a clear integration path.

To keep evaluation high-signal, I run up to a small number of NDA evals per month.

If you’re on a data platform / infra / storage team and you can point to where this fits, I’d love to hear from you.

Making JSON Compression Searchable — SEE (Schema-Aware Encoding)

kodomonocch1 — Sun, 12 Oct 2025 13:11:42 +0000

The Problem: Cloud Cost Isn’t Just Storage

Compression is easy — until you need it searchable.

Traditional codecs like gzip and Zstd reduce storage size,
but they do nothing for I/O and CPU cost.

Every query still triggers:

→ decompress → parse → filter → aggregate

If your data is JSON or NDJSON, that pipeline dominates your bill.
That’s what we call the hidden cloud tax — the cost of moving and re-reading your own data.
The Breakthrough: Schema-Aware Compression

SEE (Semantic Entropy Encoding) is a new type of codec that keeps JSON searchable while compressed.

It doesn’t just shrink bytes — it understands the structure.

Core idea:
Structure × Δ (delta) × Zstd + Bloom filters + PageDir mini-index

That means:

You can skip 99% of irrelevant data

Lookup latency ≈ 0.18 ms (p50)

Combined size ≈ 19.5% of raw

100% reproducible from the demo

Architecture in One Picture

👉 SpeakerDeck Slides

SEE vs Zstd:

Metric SEE Zstd
Combined ratio 0.194 0.137
Lookup p50 (ms) 0.18 n/a
Skip rate 0.99 0

SEE trades 5–10% of size for 90% fewer I/O ops.
At cloud scale, that’s not optimization — that’s an economic correction.

Quick Demo (10 minutes)

No build needed. Works on Windows, macOS, or Linux.

pip install see_proto
python samples/quick_demo.py

Outputs:

ratio_see[str] = 0.169
ratio_see[combined] = 0.194
skip_present = 0.99
skip_absent = 0.992
lookup_p50 = 0.18 ms

You’ll get the same metrics as the public benchmark.

Economic Impact

At $0.05/GB egress and 100 EB/month traffic:

Savings = $7.2 B/year

Payback = < 4 days

ROI ≈ 11,000%

Whoever controls SEE, controls cloud economics.

How It’s Built

Core implementation in Rust with a Zstd dictionary backend.
Python bindings (via maturin) make the demo fully reproducible.

The schema-aware layer applies:

Delta + ZigZag integer encoding

Shared dictionaries for string reuse

PageDir and mini-index for random access

Bloom filters for skip prediction

Each .see file includes a compact metadata header so partial decoding is possible.

Try It Yourself

👉 GitHub: (https://github.com/kodomonocch1/see_proto)

👉 Slides (SpeakerDeck): (https://speakerdeck.com/tetsu05/see-the-hidden-cloud-tax-breaker-schema-aware-compression-beyond-zstd)

👉 Deep dive article (Medium): (https://medium.com/@tetsutetsu11/the-hidden-cloud-tax-and-the-schema-aware-revolution-46b5038c57b8
)
If you’ve used Parquet, Zstd, or Arrow — this fits right between them,
but tuned for JSON-first workloads.

Closing Thoughts

SEE isn’t just a faster codec.
It’s a new layer of data efficiency for the cloud economy —
one that turns compression from a technical optimization into a financial advantage.

From Bytes to Balance Sheets.

PS: Discussion

If you’ve tested SEE on your own dataset (logs, telemetry, NDJSON),
share your results — we’re tracking performance across real workloads.