Crypto signal concurrent exposure analyzer

Direct answer

Concurrent exposure is a same-basis interval question

For this analyzer, concurrent planned exposure means the sum of supplied planned_risk_pct values whose time intervals are active at the same instant and whose risk_basis_id values match exactly. The page does not add a percentage based on one account, model, allocation, or notional basis to a percentage based on another. A global selected peak chooses one basis summary; it is not a cross-basis portfolio total.

Each included row must represent a resolved executed interval. The interval rule is [open, close), with close before open at an equal timestamp. User-supplied planned risk values are never summed across different risk bases.

The reported fields are maximum simultaneous signal count, peak summed planned risk, earliest peak window, overlap pair count, rows that overlapped, and share of the observed basis span with at least two rows open. Processing is browser-local and makes zero analyzer network requests.

These diagnostics are not position sizing, not correlation, not actual loss, and not advice. The synthetic example exists only to make the arithmetic reproducible.

Each row uses a half-open interval written as [opened_at_utc, closed_at_utc). The open instant belongs to the row and the close instant does not. When one row closes at exactly 13:00:00Z and another opens at exactly 13:00:00Z, those two rows have no positive-duration overlap. The event sweep applies every close before every open at that timestamp so the rule is reproducible.

Within each basis, the analyzer selects the highest active planned-risk sum. If that same sum appears in more than one event window, it retains the earliest one. The global selection compares those basis peaks by planned-risk percentage, then by earliest timestamp, then by ASCII basis ID. These tie-breaks make repeated runs produce the same result without choosing a more dramatic window.

Browser-local calculation

Analyze a concurrent exposure CSV

The five required columns are visible before the input. Additional columns are accepted as a bounded superset and reported as ignored; they do not enter interval or percentage arithmetic. File bytes are decoded with a fatal UTF-8 decoder. Pasted text and selected files remain in this browser session. The analyzer has no upload endpoint, browser storage, or network request path.

Exact method

Formulas and deterministic event order

The parser first validates the CSV shape. Header names are used exactly as supplied: they are not trimmed, repaired, or case-folded. All five required lowercase names must appear once. Unknown nonblank names can remain in the file while the published column and cell limits keep the input bounded. Every data row must match the header width. A signal ID must be unique after ASCII lowercase folding across the whole file, including rows assigned to different bases.

Timestamps accept only a real calendar date and time in the form YYYY-MM-DDTHH:MM:SSZ, with an optional one-to-nine-digit fractional second. Numeric UTC offsets, local times, leap-second values, impossible dates, and a close that is equal to or earlier than its open are rejected. Parsed instants become exact epoch-nanosecond integers. No duration ratio uses binary floating-point arithmetic.

Planned-risk percentages accept a plain base-10 decimal greater than zero and no greater than 100. A sign, exponent, thousands separator, or more than six decimal places is rejected. The accepted text becomes an integer at a scale of 1,000,000. For example, 0.125 becomes 125000 and 2.25 becomes 2250000. Active-risk sums and comparisons use those integers.

The event list sorts by integer timestamp. At each timestamp, every close is removed before any open is added. Open events are ordered by case-folded signal ID only to make pair accounting deterministic; rows opening together still overlap each other during the following positive-duration window. For each open, the current active-set size is the number of new unordered overlap pairs created by that row.

The basis span begins at its earliest open and ends at its latest close. Concurrent duration is the sum of event-window durations where at least two rows are active. The percentage multiplies the duration numerator by 100 and a fixed ratio scale of 1,000,000, divides by the span duration, and rounds half up using integers. The published decimal string is authoritative.

The reported peak window is the earliest individual event window carrying the maximum planned-risk sum. If an equal-risk close and open change the active IDs without changing the sum, the earlier window remains selected. Peak signal IDs are sorted without case distinctions and then by their original ASCII spelling. The separate peak simultaneous count is the largest active-row count observed anywhere in that basis.

Worked synthetic example

ACC-A reaches 2.25% across three signals

The synthetic starter contains four ACC-A rows and one isolated ACC-B row. ACC-A-01 runs from 08:00 to 14:00 UTC at 0.75%, ACC-A-02 runs from 10:00 to 13:00 at 0.50%, ACC-A-03 runs from 12:00 to 16:00 at 1.00%, and ACC-A-04 runs from 14:00 to 15:00 at 0.25%. The first three rows are active together from 2026-01-15T12:00:00Z to 2026-01-15T13:00:00Z, producing the selected 2.25% sum.

ACC-A has 4 unordered overlap pairs: ACC-A-01 with ACC-A-02, ACC-A-01 with ACC-A-03, ACC-A-02 with ACC-A-03, and ACC-A-03 with ACC-A-04. All 4 ACC-A rows belong to at least one pair. ACC-A-01 closes exactly when ACC-A-04 opens, so that pair is excluded by the half-open rule.

The ACC-A span is eight hours, from 08:00 to 16:00. At least two rows are active for five hours. Five divided by eight is the reported 62.5% concurrent-span share. ACC-B contains 1 isolated row, 0 overlap pairs, and a 0% concurrent-span share. Its percentage is not added to ACC-A.

Download the synthetic starter CSV or inspect the machine-readable calculation fixtures. Every row is invented for method testing and represents no provider, account, exchange, or recommendation.

Basis discipline

Why risk basis IDs must remain separate

A percentage is meaningful only against its stated denominator. Two rows can both say 1% while referring to different accounts, allocations, model sleeves, capital snapshots, or internal definitions. Adding those values would create a number that neither row supplied. The analyzer therefore treats ACC-A and ACC-B as separate groups and exposes a summary for each.

Risk basis matching uses the exact supplied token. Surrounding whitespace is not removed, and whitespace makes the token invalid under the published grammar. Case is not silently folded for basis IDs because the file owner may use case as part of an identifier. Reviewers should correct accidental spelling or case variation in their source record before analysis, document the chosen basis, and rerun the calculation. The tool will not guess that two basis strings mean the same thing.

The global selected peak is a navigation aid across summaries, not an instruction to combine them. A higher percentage in one basis appears before a lower percentage in another. Equal percentages use the earlier peak. If risk and time also match, the ASCII basis ID breaks the tie. The full basis table remains visible so the selected row cannot hide other supplied groups.

Different questions

Pairs, rows, counts, and duration are not interchangeable

Overlap-pair count describes relationships. With three mutually overlapping rows, there are three unordered pairs. Adding a fourth row that overlaps only one of those rows increases the pair count by one. The number can grow faster than row count, so it should not be read as the number of signals or time windows.

Unique rows that overlap answers a different question: how many supplied rows participate in at least one positive-duration same-basis pair? An isolated row adds one to basis row count but adds nothing to this measure. Peak simultaneous count is different again. It is the largest active-set size in one event window, regardless of whether that window carries the highest planned-risk sum.

Concurrent-span share adds time. It measures how much of the full basis span has at least two active rows. The denominator runs from the earliest open to the latest close, so inactive gaps remain in the observed basis span while adding zero concurrent duration. It does not weight that duration by planned-risk percentage. A long overlap with two small percentages can produce a larger time share than a short overlap with three larger percentages. The peak and duration fields should be read together, not substituted for each other.

A zero-overlap result is explicit. It means no same-basis pair in the supplied valid rows intersects for positive duration under the half-open rule. It does not establish that the file covers every signal, that timestamps are original, or that no exposure existed elsewhere.

Distinct job

This analyzer does one job that adjacent tools do not

The result-sheet validator owns structural repair for a wider result record: required fields, chronology, outcomes, and compatible row conventions. This page accepts bounded extra columns but uses only five fields needed for interval overlap. A file can pass this narrow analyzer while still needing the wider validator for other claims.

A point risk-reward calculator evaluates explicit payoff and probability assumptions for one setup. It does not inspect a schedule of open and close times. A sequence tool evaluates ordered resolved values. It does not find simultaneous active intervals. A coverage test compares supplied rows with a declared population. It does not add same-basis planned percentages over time.

The distinct decision here is: given these supplied interval rows and exact basis labels, when is each basis most heavily populated by planned-risk percentages, which rows create that earliest peak, and how broad is the overlap footprint? Passing that calculation does not imply that any adjacent evidence question has passed.

Reproducibility

Deterministic fixtures cover boundaries and failures

The generator executes every source-ledger fixture before writing output. The fixture family covers the exact starter result, equal-time close/open behavior, cross-day, cross-month, cross-year, leap-year and leap-century arithmetic, nanosecond rounding in both directions, one versus two UTF-8 byte-order marks, multiple bases, global peak tie-breaks, quoted superset cells, malformed quoting, missing columns, duplicate identifiers without case distinctions, invalid UTC text, non-positive intervals, risk precision and range, input limits, and a valid no-overlap set. Invalid fixtures produce no metrics.

Limitations

What this output cannot establish

The analyzer cannot authenticate a source message, recover a deleted post, detect an edited timestamp, confirm that an entry was reachable, determine whether an order was submitted, or show whether a stated stop defined the supplied percentage. It does not contact a provider, messaging platform, exchange, wallet, archive, or blockchain. It makes no provider status or quality decision.

The planned-risk sum is not account risk, account return, drawdown, actual loss, position size, leverage, margin use, liquidation distance, or capital at risk. Those concepts require additional fields and assumptions that are not present in this five-column contract. The analyzer also does not estimate dependence or common market drivers between simultaneous rows.

Planned percentages can be internally inconsistent even when parsing succeeds. A provider might change its denominator over time, reuse a basis label, publish percentages after the fact, or define risk differently across instruments. The exact basis partition prevents one kind of invalid addition; it cannot prove that the label itself is stable or truthful.

Overlap does not establish financial performance, provider verification, suitability, endorsement, or misconduct. No-overlap does not establish safety. Neither state predicts a future outcome. The page does not issue a rating, rank providers, assess legal compliance, prove search indexing, or promise retrieval or citation by an automated system.

Use the output as a review map. Preserve the original file separately, record its hash and capture time, document the meaning of each basis ID, and reconcile important rows with primary evidence. Corrections should change the source ledger and regenerate all bound artifacts instead of editing a displayed number by hand.

Privacy and local processing

The analyzer keeps supplied rows in current browser memory

Pasted text and selected file bytes are parsed by the analyzer in the current page. Its runtime contract permits no fetch, XMLHttpRequest, beacon, WebSocket, EventSource, cookie, localStorage, sessionStorage, or IndexedDB path. The page Content Security Policy also sets connect-src none. These controls govern the analyzer; the browser still requests the public page and its same-site presentation assets when the page first loads.

Issue messages expose only a stable code, severity, row number, and required-column label. They do not repeat cell values, filenames, signal IDs, risk basis IDs, unknown-column values, or raw CSV. Changing the input suppresses the previous result until the new input is analyzed.

Nothing persists automatically. Copy summary and Download JSON are explicit user actions. Copy summary writes the selected risk basis ID, peak percentage, and timestamps to the system clipboard, which the operating system or a configured sync service may retain. The JSON export writes risk basis IDs plus peak and overlapping signal IDs with the method identity, boundaries, issues, input counts, and calculated basis summaries; it excludes raw CSV and ignored-column values. Clear removes the current input and result references from the page.

Source boundary

Method and risk sources

The canonical shows only official sources that directly support CSV interpretation, timestamp grammar, or bounded trading-risk context. Operational SEO, crawler, sitemap, notification, and platform-reporting sources remain in the frozen research ledger and release handoff; they are not calculation sources. None of the links below validates a user CSV.

Dataset ID csr-crypto-signal-concurrent-exposure-analyzer-2026-07-14. Source commit b00a5584e4eadd5b308b10b5db182375eda1f0b0. The immutable source location is recorded in the machine-readable manifest without adding an unreviewed public content link.

Repair reference

Stable issue codes keep invalid inputs explicit

Errors suppress every metric because continuing would require a guess about CSV structure, identity, time, risk, or basis. Warnings and notices preserve valid arithmetic while keeping ignored columns, multiple bases, and overlap state visible. Issue order follows the frozen ledger rather than incidental browser traversal.

FAQ

Questions about concurrent exposure arithmetic

Corrections

Corrections cannot buy a conclusion

Method or route corrections can be submitted through Submit a Group. Paid production, sponsorship, profile work, or visibility services cannot buy a favorable conclusion, a verified label, a ranking position, or removal of a missing-proof note.