Description
Audit consecutive explicit non-wrapping log sequence numbers, retaining signed duplicate/reordering evidence; no modulo or missing-event certainty.
Structured log records need an explicit ordering, time unit and label convention. A sequence gap can be measured in supplied record order without proving loss, and grouping adjacent messages differs from grouping all equal messages. The record tools here operate on caller-supplied structured data rather than collecting logs.
Audit consecutive explicit non-wrapping log sequence numbers, retaining signed duplicate/reordering evidence; no modulo or missing-event certainty.
When to use this tool
Use this tool to audit consecutive explicit non-wrapping log sequence numbers, retaining signed duplicate/reordering evidence; no modulo or missing-event certainty.
How to use the tool and how it works
- Enter recordsJson using the field definitions below. For JSON text, serialize the explicit records in the shown shape.
- Run the operation. Correct input errors before interpreting an output.
- Read result.transitions. Use the ordering, boundary rules and absence conditions described below.
For each adjacent pair, return expected previous sequence + 1, observed current sequence and observed minus expected.1
| Input field | Meaning and units | Accepted input |
|---|---|---|
| recordsJson | JSON array of {id, time, source, level, message, sequence} records. Time and gap units are caller-defined; sequence is a nonnegative integer. | Text, at most 8,192 UTF-16 code units; the operation’s grammar also applies. |
These are the decoded structures used in the example’s JSON text fields. Supply the corresponding serialized JSON strings as input.
{
"recordsJson": [
{
"id": "a",
"time": 1,
"source": "s",
"level": "info",
"message": "x",
"sequence": 1
},
{
"id": "b",
"time": 3,
"source": "s",
"level": "info",
"message": "x",
"sequence": 3
}
]
}| Output field | Interpretation |
|---|---|
| result | Object containing the named fields below. |
| result.transitions | Adjacent sequence expected/observed values and observed-minus-expected deltas. |
{
"input": {
"recordsJson": "[{\"id\": \"a\", \"time\": 1, \"source\": \"s\", \"level\": \"info\", \"message\": \"x\", \"sequence\": 1}, {\"id\": \"b\", \"time\": 3, \"source\": \"s\", \"level\": \"info\", \"message\": \"x\", \"sequence\": 3}]"
},
"output": {
"result": {
"transitions": [
{
"index": 1,
"expected": 2,
"observed": 3,
"delta": 1
}
]
}
}
}Limitations and assumptions
- This checks global input adjacency, not separate per-source streams or a known start sequence.
- Structured log records have id, time, source, level, message and sequence fields. time is a finite caller-defined numeric scale; sequence is an integer from 0 through 1,000,000,000,000. Use the same time units for windows and gap edges.
- Every declared top-level input field is required and unexpected fields are rejected. Ordinary strings are limited to 8,192 UTF-16 code units and lists to 128 entries, with tighter operation-specific bounds where stated. JSON text has bounded nesting and node counts.
- Numeric outputs must be finite and no larger in absolute magnitude than the safe-integer limit; operations returning exact large integers use decimal text. Positions are zero-based and spans end exclusively unless the operation explicitly states a different convention.
Alternative or Complementary methods
Keep original record order and provenance alongside summaries. Sort, partition by source or normalize aliases explicitly before applying a rule that depends on those choices.
References
Similar or alternative tools
- Log Level Order Selector
Select supplied severity tokens at or above an explicit least-to-most ordered level bank; retain unknown tokens instead of assuming rank.
- Log Level Token Normalizer
Normalize a log-level token through explicit caller aliases with cycle/path evidence; no universal severity vocabulary.