Foundation 07 · Ordered reality
Kai, Chronos, and causality
A sovereign object cannot require a remote authority to tell it when it is. Kai-Klok makes temporal position reproducible law rather than server-issued truth; Chronos translates that position into conventional time.
What this enables
The solved state
You can preserve distinct time domains, reconstruct causal history, add correction without erasure, and keep rollover, Settlement, exit, and consent legible across time.
Governing statement
Kai-Klok removes temporal authority from infrastructure
Kai-Klok is not introduced because Receiz needed a more exotic server clock. It exists because a sovereign proof object must not depend on a privileged remote machine to tell it when it is.
The Kai-Klok specification is public and independently implementable. Its temporal position is computed from deterministic law. Receiz infrastructure may display or translate Kai coordinates, but it is not the authority that creates them.
- What was broken
- Evaluating Kai-Klok primarily as a replacement for Lamport clocks, vector clocks, NTP, or a timestamp service misses its architectural role and imports remote temporal authority back into the proof object.
- What is established
- The public specification defines the canonical mathematical system, including the phi-exact pulse, lattice, closure, exact phase arithmetic, indexing rules, rounding behavior, and implementation sanity checks.
- What you can do now
- An independent implementer can reproduce Kai temporal coordinates without a Receiz clock service or privileged timestamp issuer.
- Why it matters
- Seconds and conventional timestamps are representations of temporal position, not the authority from which Kai temporal state originates.
Two independent implementations that apply the canonical Kai-Klok law to the same temporal basis compute the same Kai position; a Receiz API may transport that coordinate but does not issue its truth.
docs/chronos-causality-kai-time-kernel.mdpackages/receiz-sdk/src/causalHistory.tsapp/utils/kai_pulse.ts
Governing statement
Kai and Chronos remain distinct
Chronos records conventional temporal location. Kai carries harmonic temporal position. Causal order records dependency. No one coordinate replaces the others.
Clock time answers when an observer placed the event. Kai answers its structured harmonic position. Causality answers which event produced the next result.
- What was broken
- A single wall-clock timestamp cannot fully establish causal order, cross-domain timing, or the structured relation between events.
- What is established
- Temporal polyphony preserves multiple exact time domains while causal history binds dependencies explicitly.
- What you can do now
- You can sort, replay, and inspect events without pretending that clock order alone proves causation.
- Why it matters
- Distributed, offline, and cross-domain events retain their actual relationship instead of being flattened into one inherited clock.
Two events may have Chronos timestamps while their Kai coordinates and causal parent establish the order required for deterministic replay.
docs/chronos-causality-kai-time-kernel.mddocs/temporal-polyphony-kernel.mdpackages/receiz-sdk/src/causalHistory.ts
Governing statement
KaiSigil — A World You Can Carry
A KaiSigil carries its identity, time, proof, visual form, memory, and application state in one file you can independently verify and continue.
KaiSigil is the portable sovereign system in which Kai law becomes visible form, deterministic identity, carried proof, inspectable memory, and continuing application state. Proof Object remains the general primitive; KaiSigil is its complete executable embodiment.
- What was broken
- Calling KaiSigil a second proof object forces the reader to compare two labels before understanding the human capability.
- What is established
- The lesson names the win first, then establishes the exact sovereign executable proof-object boundary beneath it.
- What you can do now
- You can carry one file across interfaces, reconstruct what it is, verify its declared relations, inspect what it holds, and continue supported state without asking a server to make it real.
- Why it matters
- Identity, time, visual form, proof, memory, and operation stop being fragments owned by separate infrastructure and become one portable coherent object.
A holder opens the same KaiSigil in a conforming runtime, verifies its exact artifact boundary, reproduces its glyph and Kai identity relation, inspects carried state, and exports a separately verified successor.
app/components/KaiSigil.tsxapp/verifier/validator.tsapp/components/KaiSigil/embed.tsdocs/sigil-registry-proof-payload-kernel.mdscripts/test_primitive_binding_contract.tsapp/components/KaiVoh/SigilMemoryBuilder.ts
Governing statement
Chronos becomes a Kai moment
Kai-Klok converts a conventional temporal coordinate through the Genesis anchor and phi-exact pulse law into an integer-safe Kai position: pulse, beat, step index, phase within the beat, weekday, and chakra day.
A conventional instant supplies the bridge input. Kai-Klok applies its own public law—3 + √5 seconds per pulse, 11 pulses per step, 44 steps per beat, 36 beats per day, fixed closure, and ties-to-even conversion—to derive the same structured Kai moment in every conforming implementation.
- What was broken
- A glyph can appear visually meaningful while the reader cannot see the exact deterministic path from conventional time into its carried Kai coordinate.
- What is established
- The public `klok` specification and integer-safe engine expose every constant, indexing rule, closure boundary, and rounding decision used to derive the moment.
- What you can do now
- You can reproduce the same Kai moment independently and identify where Chronos translation ends and Kai law begins.
- Why it matters
- The glyph starts from public reproducible temporal law, not an opaque timestamp service or decorative random seed.
The same Unix-millisecond input and Genesis anchor yield the same micro-pulse position, beat from 00–35, step from 00–43, phase, weekday, and chakra day without a network request.
docs/chronos-causality-kai-time-kernel.mdapp/utils/kai_pulse.tsreceiz-docs/content/kaisigil/system.ts
Governing statement
A Kai moment becomes deterministic glyph form
KaiSigil canonicalizes pulse, beat, step index, step phase, and chakra-day key; seeds deterministic generation from that state; and maps the result into chakra geometry and hue, pulse/beat harmonic parameters, rotation, light, frequency, polygon core, Lissajous aura, stable SVG identifiers, and embedded Kai state.
The visual is not selected after the fact. The carried Kai moment drives the form: chakra day chooses sides and the base hue, pulse and beat shape harmonic parameters, step phase changes color and phase, and the canonical seed keeps the render reproducible.
- What was broken
- Without the complete mapping, the sigil can be mistaken for a decorative image placed beside proof metadata.
- What is established
- The glyph-generation code exposes the direct transformation from canonical Kai inputs into stable visible geometry and carrier attributes.
- What you can do now
- You can trace every primary glyph feature back to the Kai state that produces it and test a conforming projection independently.
- Why it matters
- Time, identity, and visible form become one inspectable deterministic relationship rather than three unrelated interface claims.
Changing the admitted step or chakra-day key changes the expected seed, phase, geometry, hue, frequency, SVG identifiers, and Kai Signature relation; the verifier can reject inconsistent carried state.
app/utils/kai_pulse.tsapp/components/KaiSigil.tsxapp/components/KaiSigil/Art.tsxapp/verifier/validator.ts
Strongest object boundary
KaiSigil file
- Deterministic visual identity
- Kai temporal coordinate
- Kai Signature and Φ-Key relation
- Canonical payload and integrity
- Portable application state
- Offline verification material
Replaceable mechanics
Conforming frontend / runtime
- Parse exact artifact
- Verify enclosing object
- Recompute identity and state
- Project glyph and application
- Execute allowed operations
- Export a distinct successor
Governed extension
Receiz extension
- Authorship and presence
- Ownership and custody
- Provenance and transfer
- Settlement and Reserve
- Public witness
- Durable registers and governed appends
Authority direction: the runtime and Receiz operate beneath the verified KaiSigil artifact; neither replaces its file-carried truth.
Why it was made
A symbol of intention. A mark generated by law.
Digital meaning can be copied, detached from its moment, or made dependent on the platform presenting it. Sigil names intention; glyph names a mark produced by a structured system. KaiSigil joins them as computed form whose moment, identity relation, and declared proof material travel with the artifact.
The implementation, verifier, and exact artifact boundary below establish what the current KaiSigil proves. Human meaning does not expand a cryptographic, ownership, Settlement, biometric, or global-knowledge claim beyond implemented evidence.
What the world carries
One file. Seven coordinated boundaries.
The KaiSigil is a sovereign executable proof object and the architectural core from which Receiz grew. The complete KaiSigil artifact is the enclosing proof object. Every field below contributes to the portable system, but no individual field, digest, payload, or rendered layer outranks the verified file.
Deterministic visual identity
Kai-derived seed, polygon geometry, Lissajous aura, chakra sides and hue, phase, rotation, frequency, stable SVG identity, and canonical glyph form.
The object presents a reproducible visual identity derived from its declared Kai state.Kai state-machine coordinate
Pulse, beat, step index, chakra-day key, and deterministic order.
Temporal state is reproducible law carried with the object rather than a timestamp supplied by infrastructure.Deterministic identity relationship
The active Kai Signature and its derived Φ-Key projection.
A verifier can independently recompute the declared Kai identity relation.Canonical payload and integrity
Canonical payload bytes, BLAKE3, secondary SHA-256, and declared payload bindings.
Payload projection can be checked deterministically after the enclosing object is admitted.Declared proof material
Owner or ledger signatures, Groth16/Poseidon material, manifest hints, and verification inputs when present.
Each proof is evaluated only at its declared boundary; no subproof silently becomes complete-artifact authority.Portable application state
Ledger state, accounts, memory, transfers, payloads, proofs, and continuation inputs.
A conforming runtime can operate on state carried inside the file instead of rediscovering it from a server-owned record.Offline verification material
The fields and deterministic relations required for import, recomputation, comparison, inspection, and rejection.
A holder can verify the object without asking Receiz or an originating application to define it.Implemented now
The object leaves. Your reality goes with it.
These are current Receiz capabilities: proof is account-free, Identity adds continuity after admission, and a conforming runtime can continue supported state without becoming its authority.
Enter as yourself
Bring accepted PBI, passkey, Identity Record, Identity Seal, or Receiz Key proof into recovery and project the recovered identity immediately.
Proof remains stronger than the fresh cookie or session issued afterward.Change the intelligence, keep the memory
Carry verified, ordered history to another authorized model or runtime without asking the previous provider to remember you.
The interpreter can change; the admitted state remains the source.Carry a world between machines
Move visual identity, time, memory, supported application state, and continuation inputs together, then emit a separately verified successor.
A host executes allowed mechanics; it does not own the world or rewrite its past.Own an object that reacts to reality
Let verified live events append media, game or World state, value movement, and consequence to an object already in your custody.
New truth appends after the known proof head; it never remounts or replaces it.Settle value beyond the network
Verify receiz.account.state.v3, subtract Reserve locally into an equal held-bound Note, then consume each qualified Note head once into one whole-value successor and activate those exact bytes locally.
Local genesis and receiver activation are Settlement. Optional global publication distributes them later; it does not gate, create, or select them.Let anyone verify without joining
Give another person the exact artifact so they can inspect and verify supported proof offline without your account, app, or server.
Public verification reveals only the proof intentionally carried or disclosed.Login is not the proof. Public Record Moment, Seal File, Verify, Export, and public proof reading remain account-free. Identity adds continuity, custody, recovery, and governed private controls; session state stays beneath accepted identity proof.
From held file to continuing world
The complete KaiSigil lifecycle
Every stage preserves the same authority order: exact artifact first, verification before projection, bounded operation after admission, and a separately verified successor rather than mutation of the predecessor.
- 01
Acquire exact artifact
- Input
- Held KaiSigil file bytes.
- Authority
- The exact held file establishes the candidate object boundary.
- Operation
- Read the supported carrier without replacing bytes with interface or server state.
- Result
- A byte-held candidate KaiSigil with a declared media profile.
- Failure
- Missing, changed, empty, or unsupported bytes establish no candidate object.
Implementationapp/components/KaiVoh/SignatureEmbedder.ts · embedSignatureapp/components/KaiRealms/GlyphUtils.ts · verifyKaiSignature - 02
Verify enclosing object
- Input
- Exact held bytes and their embedded verification material.
- Authority
- The complete KaiSigil artifact outranks every embedded projection.
- Operation
- Validate the carrier, primary metadata, deterministic identity relation, and required integrity boundaries before admission.
- Result
- An admitted KaiSigil or an exact rejection.
- Failure
- A failed enclosing boundary rejects subordinate payloads even when an inner hash matches.
Implementationapp/verifier/validator.ts · validateSvgapp/components/KaiRealms/GlyphUtils.ts · verifyKaiSignature - 03
Parse admitted state
- Input
- A successfully admitted KaiSigil.
- Authority
- Parsing projects verified artifact truth; it does not create authority.
- Operation
- Decode canonical Kai state, payload, ledger, proof, memory, and link material that is present.
- Result
- A typed projection of the admitted object's carried state.
- Failure
- Malformed or inconsistent blocks are rejected or named absent without rewriting the held object.
Implementationapp/components/KaiSigil/embed.ts · buildEmbeddedBundleapp/components/KaiVoh/SignatureEmbedder.ts · embedSignatureapp/components/KaiVoh/SigilMemoryBuilder.ts · buildSigilMemory - 04
Recompute identity and state
- Input
- Admitted Kai fields and canonical payload inputs.
- Authority
- Deterministic recomputation tests the declared relationship inside the verified object.
- Operation
- Rebuild the Kai moment, glyph seed and form, active Kai Signature, Φ-Key, and declared integrity values.
- Result
- Independent agreement or a bounded mismatch for each declared relation.
- Failure
- Any mismatch rejects that relation and cannot be repaired by interface state.
Implementationdocs/chronos-causality-kai-time-kernel.md · Kai-Klok canonical lawapp/utils/kai_pulse.ts · KaiMomentapp/components/KaiSigil.tsx · KaiSigilapp/components/KaiSigil/Art.tsx · Artapp/components/VerifierStamper/sigilUtils.ts · computeKaiSignatureapp/verifier/validator.ts · validateSvgapp/components/KaiRealms/GlyphUtils.ts · verifyKaiSignature - 05
Project glyph and application
- Input
- Verified object state and deterministic operation law.
- Authority
- The verified artifact remains the source; the runtime is a replaceable projector.
- Operation
- Render visual identity, expose inspectable state, and construct the allowed interaction surface.
- Result
- A deterministic frontend experience of the held KaiSigil.
- Failure
- A host that cannot support a capability names it unavailable and must not synthesize artifact truth.
Implementationapp/components/KaiSigil.tsx · KaiSigilapp/components/KaiVoh/SigilMemoryBuilder.ts · buildSigilMemory - 06
Operate verified state
- Input
- The admitted object plus an allowed user operation.
- Authority
- Operations are constrained by carried state, declared proof boundaries, and the enclosing object.
- Operation
- Execute supported inspection, memory, ledger, transfer, payload, or continuation mechanics.
- Result
- A bounded operation result or candidate successor state.
- Failure
- Unauthorized, inconsistent, or unsupported operations produce no successor claim.
Implementationapp/components/KaiSigil/embed.ts · buildEmbeddedBundleapp/components/KaiVoh/SigilMemoryBuilder.ts · buildSigilMemory - 07
Export verified successor
- Input
- Candidate successor state and its complete carrier material.
- Authority
- Only a separately complete successor that passes its own verification becomes a new proof object.
- Operation
- Embed the successor, verify it independently, export it distinctly, and retain the predecessor unchanged.
- Result
- A new portable KaiSigil with explicit continuity to its predecessor.
- Failure
- Failed embedding or verification leaves the predecessor intact and creates no successor proof claim.
Implementationapp/components/KaiVoh/SignatureEmbedder.ts · embedSignatureapp/components/KaiVoh/SigilMemoryBuilder.ts · buildSigilMemoryapp/verifier/validator.ts · validateSvg
Time becomes recomputable identity
Kai Signature and Φ-Key
SHA-256(pulse|beat|stepIndex|chakraDayKey|intentionSigil)The producer and verifier use the same ordered preimage: pulse → beat → stepIndex → chakraDayKey → intentionSigil. When no intention is present, the final segment remains empty. The digest is 64-character lowercase hexadecimal.
Φ-Key: The active Φ-Key projection applies SHA-256 to the Kai Signature plus the φ suffix and encodes the result with Base58Check.
Exact boundary: This relation binds declared Kai state to a deterministic identity projection. It is not a public-key signature and does not independently establish artifact admission, authorship, ownership, transfer, or Settlement.
Verify without asking permission
Recompute the world. Reject the mismatch.
A verifier reads exact held bytes, validates the supported carrier and primary metadata, recomputes the Kai Signature and Φ-Key, compares deterministic Kai and integrity relations, and admits subordinate payload, ledger, proof, memory, or application projections only after the enclosing KaiSigil passes. A correct inner hash cannot rescue a failed artifact.
Every proof keeps its own boundary
Signature and proof taxonomy
| Mechanism | Establishes | Does not establish | Source |
|---|---|---|---|
| Kai Signature / kaiSignatureDeterministic KaiSigil identity relation derived from the active Kai state preimage. | Agreement between declared Kai state and the recomputed 64-character SHA-256 digest. | The complete artifact, ownership, transfer, Settlement, admission, or a public-key authorship signature. | Implementation app/components/KaiSigil.tsx · KaiSigilapp/components/VerifierStamper/sigilUtils.ts · computeKaiSignatureapp/verifier/validator.ts · validateSvg |
| Φ-KeyDeterministic identity projection derived from an admitted Kai Signature. | The expected Base58Check projection of SHA-256 over the Kai Signature plus the φ suffix. | Independent artifact admission or authority above the verified KaiSigil. | Implementation app/components/VerifierStamper/sigilUtils.ts · computeKaiSignatureapp/components/KaiRealms/GlyphUtils.ts · verifyKaiSignature |
| KKS metadata envelopeStructured carrier mechanics for Kai and KaiSigil metadata in supported files. | That declared metadata is available to a conforming parser in the supported carrier. | A new issuer, independent signature authority, ownership, or Settlement. | Implementation app/components/KaiVoh/SignatureEmbedder.ts · embedSignature |
| Owner or payload signatureAuthorship or owner binding over the declared canonical payload or ledger event. | Signature agreement for the exact declared signed message after enclosing-object admission. | Authority over unsigned fields or automatic authority for the complete carrier. | Implementation app/components/KaiSigil/embed.ts · buildEmbeddedBundle |
| KAS and PBI materialPresence, authorship, or identity continuity at the specific implemented proof boundary. | Only the declared presence, authorship, or identity-continuity statement accepted by its verifier. | The Kai Signature, generic login state, ownership transfer, or Settlement. | Implementation app/components/KaiSigil/embed.ts · buildEmbeddedBundle |
| Groth16 and Poseidon proof materialZero-knowledge proof for explicitly declared statements and public inputs. | Successful verification of that statement against those inputs. | Every fact about the artifact, owner, runtime, or Receiz extension. | Implementation app/components/KaiSigil/embed.ts · buildEmbeddedBundle |
| Receiz Signature V4Separate Receiz artifact signing and enrolled verification boundary. | The Signature V4 claim defined by the complete artifact-signing implementation. | The origin or definition of KaiSigil identity and does not replace the KaiSigil object boundary. | Implementation app/lib/security/receizSignatureV4.ts · ReceizSignatureV4 |
The whole exceeds each familiar mechanism
Why KaiSigil is a portable sovereign system
SVG
Portable visual and metadata carrier.
A graphics format alone does not establish the complete deterministic artifact, Kai state, application memory, proof boundaries, operation law, or Receiz extensions.Hashes
Integrity checks and deterministic identity projections.
No single digest contains the object's visual identity, temporal state, portable memory, operations, history, and governed extension system.Digital signatures
Bind declared messages or artifacts at distinct proof boundaries.
Kai Signature, owner signing, KAS/PBI, zero-knowledge proof material, and Signature V4 are not interchangeable and do not individually define the object.Credentials
Project a declared identity or presence relationship.
The KaiSigil also carries deterministic visual identity, temporal law, proof material, application state, memory, and continuation behavior.Runtime
Parses, verifies, presents, and operates artifact-defined state.
The host is replaceable mechanics while the exact verified artifact remains the portable object.Claim, source, consequence, limit
Claim/evidence ledger
governing-law
The file is the object
The complete KaiSigil file is a sovereign proof object whose strongest local truth travels in the artifact.
- Why it matters
- A server, session, database row, or rendered screen does not need to define the held object's identity or truth.
- Independent check
docs/sigil-registry-proof-payload-kernel.mdscripts/test_primitive_binding_contract.ts- Source
- Implementation
app/components/KaiSigil.tsx · KaiSigilapp/verifier/validator.ts · validateSvgapp/components/KaiSigil/embed.ts · buildEmbeddedBundle - Exact limit
- This claim establishes only its declared evidence boundary; interface state and subordinate projections remain beneath the artifact.
implemented
Visual identity is deterministic
Public Kai law derives the moment; canonical pulse, beat, step, phase, and chakra-day state drive the glyph seed, geometry, hue, rotation, frequency, aura, SVG identity, and visible form.
- Why it matters
- A conforming runtime can trace and reproduce the object's visual identity from carried deterministic inputs.
- Independent check
app/verifier/validator.ts- Source
- Implementation
docs/chronos-causality-kai-time-kernel.md · Kai-Klok canonical lawapp/utils/kai_pulse.ts · KaiMomentapp/components/KaiSigil.tsx · KaiSigilapp/components/KaiSigil/Art.tsx · Artapp/components/KaiVoh/SigilMemoryBuilder.ts · buildSigilMemory - Exact limit
- This claim establishes only its declared evidence boundary; interface state and subordinate projections remain beneath the artifact.
implemented
Kai Signature is independently recomputable
The active Kai Signature is SHA-256 over pulse, beat, step index, chakra-day key, and optional intention sigil joined by vertical bars.
- Why it matters
- Producer and verifier can agree without a server-issued identity response.
- Independent check
app/verifier/validator.tsapp/components/KaiRealms/GlyphUtils.ts- Source
- Implementation
app/components/KaiSigil.tsx · KaiSigilapp/components/VerifierStamper/sigilUtils.ts · computeKaiSignatureapp/verifier/validator.ts · validateSvg - Exact limit
- This deterministic digest is not a public-key signature and is not complete-artifact authority.
implemented
The artifact carries proof and application inputs
KaiSigil embedding supports canonical payload, multiple integrity hashes, owner signing, zero-knowledge material, ledger data, DHT data, and verifier hints.
- Why it matters
- A runtime can inspect and operate declared material that travels with the object.
- Independent check
app/components/KaiSigil/embed.ts- Source
- Implementation
app/components/KaiSigil/embed.ts · buildEmbeddedBundle - Exact limit
- This claim establishes only its declared evidence boundary; interface state and subordinate projections remain beneath the artifact.
implemented
Verification is offline-capable
Imported KaiSigil state can be parsed, recomputed, compared, and rejected from held artifact material without Receiz permission.
- Why it matters
- Offline operation is the primitive rather than a fallback from server truth.
- Independent check
app/verifier/validator.ts- Source
- Implementation
app/verifier/validator.ts · validateSvgapp/components/KaiRealms/GlyphUtils.ts · verifyKaiSignature - Exact limit
- This claim establishes only its declared evidence boundary; interface state and subordinate projections remain beneath the artifact.
architectural-capability
The object is executable
A conforming runtime can verify, render, inspect, operate, and continue application state carried by the KaiSigil.
- Why it matters
- Frontend experiences can execute the glyph as an application object whose state and truth travel in the file.
- Independent check
app/components/KaiVoh/SigilMemoryBuilder.ts- Source
- Implementation
app/components/KaiSigil.tsx · KaiSigilapp/components/KaiVoh/SigilMemoryBuilder.ts · buildSigilMemoryapp/components/KaiSigil/embed.ts · buildEmbeddedBundle - Exact limit
- This does not assert arbitrary embedded JavaScript or WebAssembly auto-execution.
implemented
The object can emit a successor
Supported memory and embedding paths can carry verified state forward into a distinct successor glyph.
- Why it matters
- Application continuity can Append only when the distinct successor links to the exact predecessor and independently verifies as a complete KaiSigil.
- Independent check
app/components/KaiVoh/SigilMemoryBuilder.ts- Source
- Implementation
app/components/KaiVoh/SigilMemoryBuilder.ts · buildSigilMemoryapp/components/KaiVoh/SignatureEmbedder.ts · embedSignatureapp/verifier/validator.ts · validateSvg - Exact limit
- This claim establishes only its declared evidence boundary; interface state and subordinate projections remain beneath the artifact.
governing-law
The runtime supplies mechanics
The host parses, sandboxes, presents, and executes declared operations while the admitted artifact remains the stronger source.
- Why it matters
- Different frontends can present the same object without becoming competing truth authorities.
- Independent check
docs/literal-product-law.md- Source
- Implementation
app/verifier/validator.ts · validateSvgapp/components/KaiSigil.tsx · KaiSigil - Exact limit
- This claim establishes only its declared evidence boundary; interface state and subordinate projections remain beneath the artifact.
governing-law
Receiz takes the object further
Receiz extends KaiSigil into governed authorship, ownership, custody, provenance, transfer, Settlement, public witness, registers, and appends.
- Why it matters
- Institutional operation grows from the sovereign proof object instead of replacing it with application state.
- Independent check
AGENTS.mdscripts/test_primitive_binding_contract.ts- Source
- Implementation
app/lib/security/receizSignatureV4.ts · ReceizSignatureV4app/components/KaiSigil/embed.ts · buildEmbeddedBundle - Exact limit
- This claim establishes only its declared evidence boundary; interface state and subordinate projections remain beneath the artifact.
architectural-capability
Familiar parts do not exhaust the architecture
SVG, hashes, signatures, credentials, and runtimes each supply mechanics inside the complete KaiSigil system.
- Why it matters
- Precedent for an isolated mechanism does not establish architectural equivalence with the complete object, authority order, execution model, and Receiz extension.
- Independent check
docs/reality-grade-systems-kernel.md- Source
- Implementation
app/components/KaiSigil.tsx · KaiSigilapp/components/KaiSigil/embed.ts · buildEmbeddedBundleapp/components/KaiVoh/SigilMemoryBuilder.ts · buildSigilMemoryapp/lib/security/receizSignatureV4.ts · ReceizSignatureV4 - Exact limit
- This claim establishes only its declared evidence boundary; interface state and subordinate projections remain beneath the artifact.
Power without overclaim
The complete system remains evidence-bound.
Implemented limits
- Optional proof, ledger, DHT, owner-signature, and zero-knowledge material is present only when the producing path embeds it.
- Carrier support and browser behavior remain bounded by the exact importer, embedder, verifier, and runtime paths that have been qualified.
- A local successor does not reveal unseen competing successors or establish global Settlement.
- Repository source establishes implementation; deployed browser and production state require separate dated evidence.
What this does not claim
- No private keys, credentials, production topology, or secret operational state are published by this system record.
- The Academy does not claim that SVG, hashes, digital signatures, credentials, offline verification, or host runtimes lack prior uses.
- The SVG format by itself is not the KaiSigil proof architecture.
- A self-hashable embedded payload does not outrank the complete artifact.
- The kaiSignature field alone does not prove ownership, transfer, Settlement, or artifact admission.
- A KaiSigil does not imply arbitrary JavaScript or WebAssembly automatically executes merely because the SVG file is opened.
- Every optional embedded proof field is not present in every KaiSigil.
- Offline verification does not establish global knowledge or Settlement.
- Academy prose, diagrams, source citations, and interface state are not proof authority.
- Receiz does not replace the KaiSigil's sovereign artifact truth.
Governing statement
The file is the object
The complete KaiSigil artifact is the enclosing proof object. Embedded metadata, a canonical subpayload, the kaiSignature field, a parsed ledger, a server response, and a rendered interface remain subordinate projections unless Receiz law defines a separate sealed object.
A KaiSigil is a portable file whose deterministic form, Kai state, identity relationship, proof material, verification inputs, and application state travel together as one independently inspectable object.
- What was broken
- A parsed metadata block, hash, rendered glyph, server record, or interface state can be mistaken for the authority of the complete file carrying it.
- What is established
- Verification begins with exact KaiSigil artifact bytes and admits subordinate projections only after the enclosing object passes.
- What you can do now
- You can reject an internally consistent subpayload when the stronger KaiSigil artifact fails.
- Why it matters
- No inner hash or familiar mechanism can bypass the identity, integrity, and verification law of the complete object.
A matching embedded payload hash does not admit a KaiSigil whose primary metadata, Kai identity relationship, geometry, or carrier integrity fails.
app/components/KaiSigil.tsxapp/verifier/validator.tsapp/components/KaiSigil/embed.tsdocs/sigil-registry-proof-payload-kernel.mdscripts/test_primitive_binding_contract.ts
Governing statement
The file carries the application; the runtime supplies mechanics
The artifact carries application truth, deterministic law, identity, proof, state, memory, and operation inputs. A conforming frontend or runtime supplies parsing, sandboxing, interaction, presentation, and execution mechanics without becoming the source of the KaiSigil's truth.
A conforming frontend verifies the object, projects its glyph and carried state, exposes supported operations, and can export a distinct verified successor. The host never becomes the source of the object's prior truth.
- What was broken
- Execution can be confused with server ownership of state or exaggerated into arbitrary embedded-code auto-execution.
- What is established
- Application truth and operation inputs remain in the artifact while parsing, sandboxing, interaction, and presentation remain replaceable host mechanics.
- What you can do now
- You can operate the same admitted KaiSigil through different conforming frontends without creating competing truth authorities.
- Why it matters
- The application survives any one interface because its identity, state, proof inputs, and continuity travel in the file.
A runtime imports a KaiSigil, verifies the enclosing carrier, reconstructs its glyph and memory, performs an allowed operation, and exports a new verified file while retaining the predecessor unchanged.
app/components/KaiSigil.tsxapp/components/KaiVoh/SigilMemoryBuilder.tsapp/components/KaiSigil/embed.tsapp/components/KaiVoh/SignatureEmbedder.tsapp/verifier/validator.ts
Governing statement
Independent verification travels with the object
Offline verification lets a holder import the KaiSigil, verify its enclosing boundary, recompute its Kai Signature and Φ-Key relationship, compare deterministic state and glyph inputs, inspect carried material, and reject mismatches without Receiz permission.
The verifier uses held artifact material and public deterministic law. Connectivity can discover later descendants, but it does not make the held object valid retroactively.
- What was broken
- Offline behavior can be treated as a degraded fallback that waits for a server to become authoritative again.
- What is established
- Local artifact verification is the primitive; network discovery and wider coordination remain distribution and knowledge boundaries that expose already-valid truth and do not Append.
- What you can do now
- You can inspect and verify a held KaiSigil when the original interface, session, database, or service is absent.
- Why it matters
- The object retains its inspectable identity and truth boundary under disconnection and infrastructure loss.
The verifier recomputes the declared digest and Φ-Key from pulse, beat, step index, chakra-day key, and optional intention, then rejects any inconsistent relation.
app/verifier/validator.tsapp/components/KaiRealms/GlyphUtils.ts
Governing statement
Receiz takes the sovereign system further
Receiz extends KaiSigil into governed authorship, ownership, custody, provenance, transfer, Settlement, public witness, durable registers, and governed appends without replacing its file-carried truth.
KaiSigil supplies the portable sovereign application and proof boundary. Receiz supplies institutional continuity and value-bearing operation around it.
- What was broken
- Receiz can be described as the authority that makes KaiSigil real, or KaiSigil can be reduced to one decorative feature inside Receiz.
- What is established
- The architecture preserves the direction: Kai law becomes KaiSigil; the conforming runtime operates it; Receiz composes governed primitives outward from it.
- What you can do now
- You can identify which truth travels in the original object, which Ownership, provenance, or Settlement state Receiz admits as a separately verified successor or verified register addition against the exact prior head, and which witness state it publishes.
- Why it matters
- The original sovereign breakthrough and the wider Receiz artifact system remain fully legible without collapsing either into the other.
A verified KaiSigil later participates in Receiz ownership continuity, provenance, Settlement, and public witness while its exact artifact truth remains stronger than database or session projection.
app/lib/security/receizSignatureV4.tsapp/components/KaiSigil/embed.tsAGENTS.mdscripts/test_primitive_binding_contract.ts
Governing statement
Correction extends the record
A correction is a verified causal append. Perpetual rollover preserves continuity, Settlement, exit, and consent without erasing the states that made the correction necessary.
When later proof establishes a better result, history keeps the earlier event and adds the verified correction that now governs the current projection.
- What was broken
- Mutable systems repair errors by overwriting the old state, removing the evidence required to explain the correction.
- What is established
- Causality correction and rollover preserve the prior proof while appending the governed next state.
- What you can do now
- You can audit what changed, why it changed, which proof authorized it, and which state now governs.
- Why it matters
- Correction becomes accountable progress rather than invisible revision.
A verified correction event names its causal parent, joins append-only history, and changes the present projection without deleting the earlier record.
docs/causality-correction-kernel.mddocs/perpetual-rollover-kernel.mdpackages/receiz-sdk/src/causalReplay.ts
Governing statement
Temporal validity is not global omniscience
A deterministic Kai coordinate establishes reproducible temporal position for the evidence in hand. It does not establish knowledge of unseen competing descendants or admission into a separate external proof domain. An accepted local claim can already be Settlement inside its implemented domain.
Local validity and local Settlement remain distinct from global knowledge and external-domain admission. Connected infrastructure may discover, admit, synchronize, or coordinate additional state; connectivity does not retroactively create the truth already carried and accepted from verified evidence.
- What was broken
- A reproducible local coordinate can be overstated as knowledge of every event or understated as invalid until a remote service confirms it.
- What is established
- Kai law establishes the object's temporal coordinate; received verified history establishes known causal state; broader domains establish only their declared admission and finality claims.
- What you can do now
- You can use Kai-Klok without granting a server temporal authority and without claiming global knowledge from local possession.
- Why it matters
- The authority-removal architecture stays exact at both boundaries: it preserves sovereign local proof and refuses unsupported global claims.
An offline artifact retains its deterministic Kai coordinate. A later connected synchronization may reveal a competing descendant, but it does not create the earlier coordinate or erase the earlier locally valid evidence.
docs/chronos-causality-kai-time-kernel.mddocs/offline-verified-register.mdpackages/receiz-sdk/src/causalReplay.ts
Public specification