External technical review request

[div0rce]

Quant Systems Lab actively wants adversarial technical criticism. As of now no external review has happened — every claim is self-certified — so this issue is an open, standing invitation to attack the parts most likely to be wrong.

Full context and per-area links: docs/review_request.md.

Where criticism is most valuable

1. SPSC ring-buffer memory ordering — acquire/release correctness + the wait-free-per-op claim. (docs/memory_ordering.md, include/qsl/concurrency/spsc_ring.hpp)
2. Backpressure semantics — is bounded-queue backpressure actually lossless? (docs/concurrency_model.md, tests/concurrency/test_backpressure.cpp)
3. Threaded ownership model — single-owner engine, value hand-off across SPSC queues. (docs/concurrency_model.md, include/qsl/concurrency/pipeline.hpp)
4. Event-log integrity under concurrency — no silent drops, drain-on-shutdown, replay equivalence. (tests/concurrency/test_pipeline.cpp)
5. Benchmark / profiling methodology — synthetic, measured, honestly caveated. (docs/benchmarking.md, docs/perf_analysis.md)
6. Linux / socket profiling methodology — user/kernel CPU split, UDP loss = published − received, loopback limits. (docs/socket_profiling.md, docs/socket_hardening.md)

How to help

• Comment here, or open a PR with a fix + short rationale.
• For a new, separate finding, the review-request issue template gives a structure.
• Outcomes (accepted and rejected, with rationale) are recorded in docs/review_feedback.md, so the review history stays auditable.

---

This is a deterministic exchange simulator and portfolio systems project — not a production exchange, not connected to real markets, and it makes no latency, throughput, or profitability claims. Dynamic analysis (sanitizers, TSan, stress, differential testing) is empirical evidence over executed cases, not a proof. Please keep feedback technical.

[stevesagronegocios673-ux]

Quick review-request / README note after reading the issue, README, docs/review_request.md, and docs/memory_ordering.md: the project is unusually good at saying what it is not. The README’s “not a production exchange,” “no profitability claims,” and microbenchmark caveats do a lot of trust work before the reader reaches the technical details.

The one thing I would tighten is the first external-review path. Right now the review request lists six valuable areas, but all six are fairly deep. A good external reviewer may bounce because every path feels like a full concurrency/perf audit. I would add a smaller “30-minute review path” above the six areas.

Something like:

If you only have 30 minutes, review one claim boundary:
1. Pick one claim below.
2. Check whether the linked README/docs state exactly what the evidence proves and does not prove.
3. File one issue if the claim is too broad, under-evidenced, or missing a caveat.

Then give three starter prompts:

• Does the README make the benchmark numbers impossible to confuse with production latency?
• Does memory_ordering.md scope “wait-free per operation” tightly enough to exclude caller-side spinning?
• Does the socket profiling language make loopback/constrained-environment evidence visible before any numbers?

That would turn the review request from “please audit the hard parts” into “here is the smallest useful criticism you can give.” It should increase the chance of getting the first external review recorded.

For the SPSC section specifically, I like that memory_ordering.md explains both release/acquire directions: producer publishes data through tail_, consumer publishes freed slots through head_. The doc also correctly separates queue-operation wait-freedom from application-level backpressure. I would make that separation even more visible in docs/review_request.md, because it is exactly where a reviewer is likely to challenge the claim.

A possible wording tweak:

The queue operation is claimed wait-free only for bounded, non-blocking payload movement. A caller loop that retries on full/empty is application-level backpressure and is not claimed wait-free.

One more useful addition: add an “External review ledger states” mini-table to the review request itself, not only a link to review_feedback.md:

No review yet -> self-certified only
Accepted criticism -> recorded with fix or follow-up
Rejected criticism -> recorded with rationale
Open criticism -> linked until resolved

That makes the evidence standard visible at the moment someone is deciding whether to comment.

Want the fuller pass? I can send a tightened review-request opening + 5 concrete README/docs edits for making the first external review easier to get.

[div0rce]

Quick review-request / README note after reading the issue, README, docs/review_request.md, and docs/memory_ordering.md: the project is unusually good at saying what it is not. The README’s “not a production exchange,” “no profitability claims,” and microbenchmark caveats do a lot of trust work before the reader reaches the technical details.

The one thing I would tighten is the first external-review path. Right now the review request lists six valuable areas, but all six are fairly deep. A good external reviewer may bounce because every path feels like a full concurrency/perf audit. I would add a smaller “30-minute review path” above the six areas.

Something like:

If you only have 30 minutes, review one claim boundary:
1. Pick one claim below.
2. Check whether the linked README/docs state exactly what the evidence proves and does not prove.
3. File one issue if the claim is too broad, under-evidenced, or missing a caveat.

Then give three starter prompts:

• Does the README make the benchmark numbers impossible to confuse with production latency?
• Does memory_ordering.md scope “wait-free per operation” tightly enough to exclude caller-side spinning?
• Does the socket profiling language make loopback/constrained-environment evidence visible before any numbers?

That would turn the review request from “please audit the hard parts” into “here is the smallest useful criticism you can give.” It should increase the chance of getting the first external review recorded.

For the SPSC section specifically, I like that memory_ordering.md explains both release/acquire directions: producer publishes data through tail_, consumer publishes freed slots through head_. The doc also correctly separates queue-operation wait-freedom from application-level backpressure. I would make that separation even more visible in docs/review_request.md, because it is exactly where a reviewer is likely to challenge the claim.

A possible wording tweak:

The queue operation is claimed wait-free only for bounded, non-blocking payload movement. A caller loop that retries on full/empty is application-level backpressure and is not claimed wait-free.

One more useful addition: add an “External review ledger states” mini-table to the review request itself, not only a link to review_feedback.md:

No review yet -> self-certified only
Accepted criticism -> recorded with fix or follow-up
Rejected criticism -> recorded with rationale
Open criticism -> linked until resolved

That makes the evidence standard visible at the moment someone is deciding whether to comment.

Want the fuller pass? I can send a tightened review-request opening + 5 concrete README/docs edits for making the first external review easier to get.

chatgpt wont save you