RANKIGI × EVIDE

This document defines a minimal interoperability boundary between an execution-layer system (RANKIGI / KYA) and an evidentiary responsibility layer (EVIDE), enabling the generation of a portable, independently verifiable closure record.

The objective is not system integration, but boundary definition:

• execution proof (what happened)
• responsibility closure (who is accountable)
• evidentiary portability (can it be proven outside the system)

This mapping was developed through direct technical collaboration between independent systems and validated at the architectural level.

This document defines only the interface layer. It does not modify the native RANKIGI or EVIDE schemas.

The objective is to establish a stable handshake between:

• execution-level evidence (RANKIGI / KYA)
• responsibility closure object (EVIDE)
• independent evidentiary export (FEDIS-compatible)

Execution proof and responsibility proof are not the same object.

• RANKIGI (KYA) provides a tamper-evident execution chain.
• EVIDE defines a structured responsibility closure object.
• FEDIS enables independent verification and legal admissibility.

The closure object does not exist inside the execution chain. It is anchored alongside it, and remains portable outside the originating system.

EVIDE reference: External Evidentiary Deposit – EVIDE

The following represents a minimal alignment between systems at the closure boundary.

Before hashing and anchoring, the closure object must be normalized.

• deterministic field ordering
• UTF-8 encoding
• no environment-dependent fields
• no runtime-dependent metadata
• stable serialization format (JSON canonicalization)

The normalized object is the only valid input for hashing. This ensures:

• reproducibility of the hash
• independence from system implementation
• consistency across verification environments

The architecture relies on two independent integrity layers.

• event-level hash chaining
• RFC 3161 timestamping at execution level

• independent closure object hashing
• RFC 3161 timestamping at closure level

Both must exist independently.

The closure object sits alongside the KYA chain, not inside it. The source_event_ref field bridges the two layers without merging them.

The exported closure record must be self-validating. It must allow a third party to verify the record without:

• access to RANKIGI infrastructure
• access to EVIDE systems
• privileged APIs or internal logs

• reference to originating chain event (event_hash) as recorded at the closure moment
• normalized closure object
• normalization rules used (see Section 2)
• closure object hash
• RFC 3161 timestamp proof (closure level)
• authority reference (external identity baseline)
• authority proof (e.g. passport_certificate or equivalent external verification artifact)

• previous_hash reference
• subject lifecycle snapshot

A closure record is considered valid if:

• the closure object is complete, declared, and explicitly attributed
• the hash matches the normalized object
• the RFC 3161 timestamp is valid and verifiable
• the authority reference is externally resolvable
• the source_event_ref correctly links to the execution chain

Failure in any of these conditions results in:

• invalid evidentiary closure
• non-portable record
• dependency on originating system

The originating execution substrate must conform to KYA Standard or KYA Extended. KYA Basic conformance is insufficient for FEDIS compatibility.

Rationale: KYA Basic leaves the X.509 fields optional, which means the authority reference is not guaranteed to be externally resolvable. KYA Standard makes those fields required, satisfying the authority resolution requirement at the FEDIS output stage.

Reference: KYA specification Section 3.5 (Issuer Authority and External Verifiability) and Section 9 (Conformance Levels).

The portable closure record must be compatible with the FEDIS evidentiary model.

Reference: https://www.certifywebcontent.com/fedis-forensic-evidence-declaration-integrity-statement/

FEDIS defines how the closure record becomes:

• independently verifiable
• legally presentable
• usable in audit, regulatory, and judicial contexts

Important:

FEDIS is not a default system artifact. It is a formal evidentiary output generated through a certification process.

The interface defined in this document ensures that the closure record can be used as a valid input for FEDIS generation.

The KYA passport_certificate + chain export (KYA Section 8, compliance table) constitutes the defined entry point for FEDIS closure record input.