The sealed peer channel's measurement-binding property is stated as present fact in the README, while LIMITATIONS says it must not be assumed yet.
Stated as fact:
README.md:57 — "The task payload is sealed to the peer's attested measurement, so it decrypts only inside the verified enclave."README.md:88,94 — "seal task payload to peer measurement" / "only B's verified enclave can read it."
Caveated in LIMITATIONS:
LIMITATIONS.md:13 — "The remaining gap is the hardware property that the private key never leaves the peer's enclave ... Until that end-to-end binding lands on hardware, do not assume a payload is confined to a specific attested measurement."
Also, the one-line status differs across docs: the README banner (README.md:26) calls the sealed channel "under construction," while ROADMAP.md:26 marks it "landed" (with the hardware binding listed as remaining work). Both are defensible in the detailed text, but a reader hits contradictory headline words.
Proposed fix: at the point of claim (README.md:57, :88-94), add the qualifier that the channel crypto is implemented but sealing to a verified attested measurement is roadmap (per LIMITATIONS.md:13), and align the one-line status wording across the README banner, LIMITATIONS, and ROADMAP.
(The LIMITATIONS / ROADMAP discipline here is good — this is only about the README stating the end-state property without the in-progress qualifier.)
Found during a docs-consistency pass.
The sealed peer channel's measurement-binding property is stated as present fact in the README, while LIMITATIONS says it must not be assumed yet.
Stated as fact:
README.md:57— "The task payload is sealed to the peer's attested measurement, so it decrypts only inside the verified enclave."README.md:88,94— "seal task payload to peer measurement" / "only B's verified enclave can read it."Caveated in LIMITATIONS:
LIMITATIONS.md:13— "The remaining gap is the hardware property that the private key never leaves the peer's enclave ... Until that end-to-end binding lands on hardware, do not assume a payload is confined to a specific attested measurement."Also, the one-line status differs across docs: the README banner (
README.md:26) calls the sealed channel "under construction," whileROADMAP.md:26marks it "landed" (with the hardware binding listed as remaining work). Both are defensible in the detailed text, but a reader hits contradictory headline words.Proposed fix: at the point of claim (
README.md:57,:88-94), add the qualifier that the channel crypto is implemented but sealing to a verified attested measurement is roadmap (perLIMITATIONS.md:13), and align the one-line status wording across the README banner, LIMITATIONS, and ROADMAP.(The LIMITATIONS / ROADMAP discipline here is good — this is only about the README stating the end-state property without the in-progress qualifier.)
Found during a docs-consistency pass.