From enrollment to a verifiable timeline
1. Enroll a signer within its scope
While signed in online, create the project dossier, register a branch and enroll a public key. Events are bound to that account, project, branch and logical device.
2. Sign and retain pending events
In compatible browsers, prepare declared events in the encrypted local queue. The Ed25519 signature, sequence number and previous hash reference form the envelope sent to the server.
3. Sync and review exceptions
Sync requires the same account online. An ACK is returned after the event is recorded; after an uncertain response, retain the reference and query or resend the same envelope without changing the chain or silently creating another event.
Current service configuration
Published capabilities describe the service; they do not grant your account permission or prove immediate availability. Operation requires a current project pilot; local capability also depends on the browser and the key retained by the user.
Intake of signed declared events
Checking…Branch-scoped public-key enrollment
Checking…Private timeline of received events
Checking…Explainable declared-data crosschecks
Checking…Private JSON and TXT exports
Checking…ViciousByte evidence signature
Checking…Physical equipment control
Hardware control not implementedVerification of physical events
Does not verify physical truthFiscal authenticity certification
Does not verify fiscal authenticityPayment execution
Payment execution not implemented
What each piece of evidence supports
Enrolling a public key does not by itself demonstrate possession: this is checked when a valid signed event is received. Event signing verifies an enrolled key and its declared content. The optional ViciousByte signature covers a manifest with hashes of the dossier, events and report; the export preserves those objects so their hashes can be recalculated. It does not directly sign the whole body or certify its physical truth. The dashboard attaches or downloads the attestation; it does not claim local cryptographic verification.
Sequence and hash chain support continuity checks within one signer and detection of received-envelope conflicts. An empty queue or an accepted chain does not prove that every physical event was recorded. A pending event has no server acknowledgement yet.
The timeline preserves scope, references and declared timestamps alongside the server reception time. Ticket, CFDI and reading references are submitted data, not proof of payment, fiscal stamping or certified measurement.
Exceptions explain differences or relationships in received data under published rules. Coverage is bounded; missing evidence or absence of an exception does not amount to a complete physical audit or compliance certification.
Encrypted local queue: custody and limits
The dashboard uses an AES-GCM vault with a random key retained by the user. The Ed25519 private key and pending queue are stored encrypted; they can persist across reloads or sign-out while the browser retains the data. Perpetual storage is not promised.
Unlocking the vault is local: it does not sign in, grant project access or authorize APIs. Sync requires the same account authenticated online and access confirmed by the server; retiring a device may prevent its pending queue from being received.
A vault copy and its key can clone the signer: no unique hardware identity is claimed. Keep both under your custody. If the key is lost or local data is erased, recovery of the private key or events not yet received by the server is not guaranteed.
Queue sync uses explicit actions in the open dashboard. Background operation, autonomy without a session or connection, universal browser support and integration with readers, registers or physical devices are not promised.
Published dossier, capacity and budget
Declared-event envelopes require a signature in addition to ordinary authentication. No commands are sent to equipment, no external connectors are queried, and no payments or fund movements are executed.
Access requires pilot branch_event units, separately from other services. Admission budgets and dossier capacity are distinct operational limits, not prices or automatic charges.
Current limits could not be confirmed. Check the catalog or dashboard; capacity, retention and sync permission are not assumed.
Private scope and fixed expiry
Branches, logical devices and events belong to the same account and project, including for administrators. Submit only data you are entitled to process, and avoid unnecessary sensitive content in tickets, references or readings.
Retiring a branch or revoking a device blocks new events in that scope while preserving history within dossier retention. It does not free lifetime capacity or verify the physical origin of the signer.
Deleting the dossier or reaching its expiry blocks its reads and new publication, then queues server data for asynchronous purge. Remote deletion cannot erase disconnected local copies: custody and removal are managed in the browser. Sync does not revive an expired dossier or extend its deadline.
Branch Audit requires an explicit pilot approved for your account and project, with its own budget. Plans for other services do not enable it. Requesting access records pending interest for review; it grants no permission and starts no payment.
Request pilot access
Register a Branch operations audit request for your account. This does not create a subscription, activate permissions or execute a payment.