Knowledge Timestamp Receipt: settling the latest moment an organisation could have first known

The problem

Regulatory reporting deadlines run from knowledge. Something is discovered, and a clock starts. The clock is defined in terms of when the organisation knew, or reasonably should have known, and then some number of hours or days later a filing is due.

The clock has no reliable start. What exists is a monitoring system that raised an alert, a ticket opened later, a chat message where somebody said this looks bad, and a formal determination days after that. Every one of these carries a timestamp from a system the organisation controls, and every one is contested.

Name the parties. The firm asserts that knowledge began at the moment of formal determination, because before that there were only unconfirmed signals. The regulator asserts it began when the first alert fired. A plaintiff's lawyer asserts it began earlier still, pointing at a metric that was drifting for two weeks. An insurer defending a late notice claim asserts whatever helps. Nobody can settle it, because the underlying artifacts are rows in mutable stores, produced by systems whose configuration nobody recorded.

Three specific failures make this unsettleable.

The first is the human filter. Alert pipelines usually have a person or an approval step between detection and any durable record. That step exists for good reasons, since most alerts are noise. It also means the durable record of an incident begins when somebody decided it was worth one, and that decision was made by a party with an interest in the answer.

The second is the moving system. A detection depends entirely on what the detecting system was running. A rule version deployed on Tuesday would have fired on Monday's data, or would not have. Firms rarely record which build and which rule set produced which alert, so any later reconstruction is guesswork.

The third is that the evidence is dangerous to hold. A detection artifact contains network addresses, file paths, account identifiers, and often the details of a live vulnerability. An instrument that fixes the timeline by publishing the artifact creates a worse exposure than the one it documents.

When the detecting party is autonomous the human filter argument collapses. There was no human. The system detected and acted in milliseconds. Whatever the organisation later says about when it knew, the machine's own record is the only record, and if that record was minted through a path with an approval gate then it was never the machine's record at all.

What the receipt binds

The schema is at https://thehiveryiq.com/.well-known/schemas/knowledge-timestamp-v1.json.

The time_source enum is worth reading: gnss_disciplined_ptp, gnss_disciplined_ntp, national_time_service, timestamp_authority_token, public_chain_head_witness and multi_source_quorum. There is no option for the local clock.

What is deliberately not in the signed body

The detection artifact is absent. What appears is indicator.digest_sha256, a commitment under one of two schemes. Under sha256 it is a plain hash of the artifact. Under hmac_sha256_epoch_key it is keyed to a salt epoch, identified by a date in salt_epoch, and the key never appears. The optional artifact_byte_length lets a later holder confirm size without content.

INDICATOR_OPACITY enforces the absence. It walks the signed strings and rejects five plaintext shapes: a currency amount, an internet protocol version four address, an internet protocol version six address, an electronic mail address, and a file path in either Windows or POSIX form. The same gate requires the salt epoch to be present exactly when the scheme is keyed, so a plain digest carrying a salt epoch and a keyed scheme missing one both fail.

The receipt uses the shared typed receipt construction in src/typed/canon.js: canonical JSON with keys sorted recursively, no whitespace, non ASCII escaped as lowercase \uXXXX, lowercase hex SHA-256 over the UTF-8 bytes, and Ed25519 over the ASCII string

hive-receipt <receipt_id> <payload_sha256> <ts>

The chain uses a second commitment. sequence.prev_payload_sha256 is the recomputed canonical digest of the predecessor's signed body, so no entry can be inserted, removed or edited without breaking the link at that point.

The bound the receipt produces is computed rather than declared. On a passing verification the result carries earliest_consistent at the anchor instant minus the drift bound, latest_bound at the anchor instant plus the drift bound, and operative_end set to latest_bound. The interval is symmetric around the anchor and only its upper end is operative, which is exactly what the boundary text claims.

The gates

Verification runs in this order and stops at the first failure.

1. SCHEMA. Validates the envelope against the knowledge timestamp v1 schema. A failure means the artifact is malformed or carries a property the schema does not permit.
2. ISSUER_KEY_MATCH. Resolves envelope.key_id in the trusted keyring. A failure means the key does not resolve there.
3. PAYLOAD_DIGEST, RECEIPT_ID, SIGNATURE and SIGNER_IDENTITY. The shared envelope layer. The canonical digest of signed_body is recomputed against payload_sha256, the identifier has to parse and declare the same type as the body, the Ed25519 signature has to verify, and SIGNER_IDENTITY fails when only a caller supplied key verified.
4. DETECTING_SYSTEM_BINDING. Requires the signing key to be the designated key the registry binds to this system and tenant. A failure means one sensor's key signed for another sensor, or that no registry was supplied at all.
5. AUTONOMOUS_EMITTER. Requires an autonomous mode, no approval event, and an asserted absence of any approval gate. A failure means a human sat in the mint path.
6. MINT_LATENCY_BOUND. Requires the declared latency to sit inside the declared bound and to reconcile with the envelope timestamp. A failure means the gap between detection and minting is larger than declared, or the declaration does not agree with the envelope.
7. ANCHOR_DECLARATION. Requires the named anchoring authority to resolve, to permit the declared source class, and to stand behind the declared drift bound. A failure means the time claim rests on an authority that does not exist or does not support it.
8. ANCHOR_LOCAL_CONSISTENCY. Requires the disclosed offset to equal the anchored instant minus the local instant, inside the configured skew. A failure means the declared offset does not describe the two instants in the receipt.
9. CHAIN_PREV_LINK. Requires the genesis form, or a supplied predecessor whose identity, recomputed digest, chain and anchored instant match this body. A failure means the previous link is missing, misnamed or misdescribed.
10. SEQUENCE_MONOTONICITY. Requires consecutive positions in one chain and, when a successor is supplied, a successor whose predecessor digest recomputes against this body. A failure means a gap, a repeat, or a successor that points somewhere else.
11. ANCHOR_MONOTONICITY. Requires the repeated predecessor instant to be true and the anchored instants not to run backward beyond the declared uncertainty. A failure means the chain's time order is impossible.
12. SOFTWARE_IDENTITY_PIN. Requires both pinned digests to resolve with the declared labels and to be available at the anchored instant. A failure means the build or rule set was not what the receipt names, or did not exist yet when the detection is claimed.
13. INDICATOR_OPACITY. Requires a well formed commitment, a salt epoch exactly when the scheme is keyed, and no plaintext indicator in any other signed string. A failure names the path and the shape found.
14. FORWARD_LINK_FORM. Requires directional, unique, recomputable links, and an empty array on a detection receipt that opens its own incident. A failure means the incident graph is malformed.
15. BOUNDARY_CONSTANT. Requires the signed boundary text to equal the schema constant character for character. A failure means the non attestation was edited.

Three of these fail closed. An unsupplied detecting system key registry fails DETECTING_SYSTEM_BINDING, an unsupplied anchoring authority registry fails ANCHOR_DECLARATION, and an unsupplied software and rule set registry fails SOFTWARE_IDENTITY_PIN. Absent evidence produces a failure, never a pass.

The boundary

This receipt attests only that a named detecting system, running a digest pinned software build and a digest pinned rule version, committed the digest of a detection artifact at an instant supplied by a named external time anchor with a declared drift bound, at a stated position in a named append only hash chained sequence, with no human approval in its mint path. It bounds the latest instant at which that system can later be said to have first held the committed artifact, and it does not establish the earliest such instant. It does not attest that the detection was correct, that the committed artifact described a real condition, or that any condition existed at all, and it does not decide whether any response was reasonable, timely, adequate, or complete. It does not decide whether any materiality, significance, or de minimis assessment was right, it makes no such assessment, and it does not determine that any reporting obligation applies, that any deadline was met or missed, or that any rule, regulation, contract, or duty was complied with or breached. It does not identify any affected system, person, account, or asset, it does not disclose the content of the committed artifact, it does not authorise, require, or excuse any notification, escalation, disclosure, remediation, or enforcement action, and it fixes the timeline to which those judgments are applied and nothing more.

BOUNDARY_CONSTANT checks that text character for character against the schema constant.

The last clause is the whole design: it fixes the timeline to which those judgments are applied and nothing more. Whether an incident was material, whether the response was adequate, whether the filing was on time, none of that can be mechanised, and an instrument that pretended to mechanise it would be rejected by every reader who matters. What can be mechanised is the timeline those judgments apply to, and today that timeline is the weakest part of every incident record. A regulator can look at a receipt that explicitly makes no materiality assessment and use it as a fact input rather than treating it as an attempt to preempt their determination.

The sentence about the earliest instant is the honest one. A cryptographic commitment can prove a thing existed by a certain time. It cannot prove a thing did not exist earlier. A firm that held the artifact for a week before committing it has a receipt that says nothing about that week.

The clause about not identifying any affected system is what makes the receipt shareable. A firm can hand this to a regulator, an insurer, a counterparty and a court without disclosing a live vulnerability. That is the difference between an instrument used during an incident and one used afterward.

Adversarial cases

From test/knowledge-timestamp.test.mjs.

Emitter mode automatic fails SCHEMA, and an additional signed property alert_text fails SCHEMA. The mode enum does not include a vague middle option, and there is nowhere to paste an alert body. A registry binding the key to another sensor fails DETECTING_SYSTEM_BINDING.

Autonomous mode naming an approval principal fails AUTONOMOUS_EMITTER. So does a dormant approval gate that auto approved, and an agent identifier without the autonomous prefix. The gate wants a mint path with no human decision point, not merely one where nobody happened to intervene. A latency of 96000 against a 5000 bound fails MINT_LATENCY_BOUND, and a declared latency that does not reconcile with the envelope timestamp fails too.

A drift bound below the registry minimum fails ANCHOR_DECLARATION. Declaring a tighter accuracy than the anchoring authority stands behind is caught. An anchoring authority absent from the registry fails the same gate. A local offset of 900 against a two millisecond difference fails ANCHOR_LOCAL_CONSISTENCY, and a local clock four hours behind the anchor fails as well.

A predecessor digest that does not recompute fails CHAIN_PREV_LINK. A genesis predecessor claimed at a nonzero position fails too, which blocks the trick of starting a fresh chain in the middle of an incident. A repeated prev_anchor_time that is not the predecessor instant fails the same gate.

A gap of two positions fails SEQUENCE_MONOTONICITY, a repeated position fails, and a successor recording another predecessor digest fails. This is the deletion attack: remove the inconvenient early detection and the chain no longer counts consecutively.

An anchored instant a week before the predecessor fails ANCHOR_MONOTONICITY. A signed prev_anchor_time later than the anchored instant fails before the predecessor is even fetched.

A rule set not yet available at the anchored instant fails SOFTWARE_IDENTITY_PIN. Claiming a detection made by a rule that did not exist yet is the retrospective detection, and it is refused. A software label disagreeing with the registry fails the same gate.

A network address in a signed identifier fails INDICATOR_OPACITY. A plain digest scheme carrying a salt epoch fails, and a keyed scheme without one fails.

Non empty forward links on a detection receipt fails FORWARD_LINK_FORM. A detection that opens its own incident cannot already point at its own remediation. A backward link pointing forward fails, and a linked envelope in another incident fails.

Boundary text with the materiality sentence removed fails BOUNDARY_CONSTANT. That is the exact case tested, and it is the sentence somebody would most want to remove. A signed body mutated after signing fails PAYLOAD_DIGEST.

The mint path is tested too. It derives an empty link array, an autonomous emitter and the local offset rather than accepting them, and refuses a human approved request, an over bound latency, supplied links and a plaintext indicator.

Performance

From hive-verifier-api/benchmarks/results-latest.json, measured at 2026-08-09T22:28:01.099Z at commit e167719f7d815809c6f55c5dde4495edf1c5615f over 200 iterations:

Local harness measurement on one machine and one Node version, recorded on Node v20.20.1, linux/x64, two Intel Xeon cores at 2.90 GHz. It is a reproducible measurement of this code, not a production latency guarantee. This is among the fastest verify paths of the deployed types in this run, which matters here more than elsewhere: a receipt minted inside a declared latency bound with no human in the path needs a mint cost well under that bound.

How to run it

• Host: https://thehiveryiq.com/v1
• Verify route: /verify/knowledge-timestamp, no credentials required
• Mint route: /mint/knowledge/timestamp, requires Authorization: Bearer $HIVE_TYPED_MINT_TOKEN

curl -sS -X POST https://thehiveryiq.com/v1/verify/knowledge-timestamp -H 'content-type: application/json' -d '{"receipt": <a receipt of this type>}'

Mint fails closed with 401 when the token is missing.

Where it sits in the canon

Family: incident evidence. Category: typed receipt contract.

It chains to itself. One incident is a sequence of these receipts sharing a chain_id and an incident_ref, with forward_links recording the roles of later entries: escalation, assessment, materiality determination, notification, remediation, closure. The detection entry that opens an incident carries no forward links, and everything after it links back. It does not replace a detection system, an incident response process, or a regulatory filing.

Status

production_deployed.