ECAI Knowledge Encoding Format (EKEF v0.3): Research Draft
A historical tuple-encoding proposal, its unresolved format requirements and links to current implementation references.
Status of this draft
EKEF v0.3 is an earlier representation proposal, not the authoritative format for every current ECAI index or API. Confirm the schema used by the installed module before exchanging records. The implementation guides describe the current documented interfaces and their validation scope.
Proposed record shape
The draft proposed an ordered tuple of subject, predicate, object, context and timestamp. For example:
["fixture-42", "has_status", "accepted", "demo-corpus", 1712493296]
This is illustrative data. It does not assert the truth of a statement or establish the exact runtime wire format.
Requirements before interoperability can be claimed
- Define text encoding, normalisation and treatment of case and whitespace.
- Define field types, lengths, timestamp semantics and versioning.
- Specify the exact serialisation; the earlier “VRLP” label is not sufficient.
- Preserve original records and distinguish content identity from query keys.
- If curve mapping is needed, specify the suite and test vectors.
- Define signatures, trust anchors, permissions and migration behaviour.
The earlier sample used an unspecified encoder and curve API and did not provide a validated interoperable implementation. It has been removed from this reference rather than presented as runnable production code.
Relationship to knowledge releases
A record format can support checkable artifacts when it is precisely specified. It does not alone implement on-chain reasoning, semantic consensus, an NFT marketplace or retrieval without stored data. Read encoding boundaries and index-release implementation limits.