docs: correct claim that RFC-0001 specifies Doll origin.doll_id

docs/faq.md

@@ -146,7 +146,7 @@ This is the same principle that underlies secure software design more broadly: v
 
 **A:** A proposal is a structured candidate change generated by a self-improvement loop and submitted to the Ward authority layer for evaluation. A proposal is not an instruction to the familiar and not an edit applied directly to the harness. It is a candidate — something that might be applied, pending Ward evaluation.
 
-Structurally, a proposal includes: a unique identifier; the identity of the loop that generated it (`origin.doll_id` for Doll proposals, or the familiar ID for self-generated proposals); the set of files and blocks the proposal targets; the proposed diff; optionally, metadata about why the change is being proposed and what performance signal motivated it.
+Structurally, a proposal includes: a unique identifier; the identity of the loop that generated it (the familiar ID for self-generated proposals, or — in the Coven architecture, not yet specified in the RFC — an origin discriminator such as `origin.doll_id` for Doll proposals); the set of files and blocks the proposal targets; the proposed diff; optionally, metadata about why the change is being proposed and what performance signal motivated it.
 
 Proposals can come from several sources. The primary intended source is a self-improvement loop like Self-Harness or SkillOpt — an autonomous process that analyzes the familiar's recent performance, identifies changes to the scaffolding that might improve it, and submits proposals for Ward evaluation. Proposals can also be generated by the familiar's own maintenance processes — for example, a heartbeat process that detects an outdated tool default and proposes a configuration update. Proposals can also come from human-initiated change processes, though human-initiated changes at higher authorization levels often bypass the lower approval tiers.
 

docs/ward-deep-dive.md

@@ -368,7 +368,7 @@ In a Coven with multiple familiars, a proposal from one familiar might interact
 
 ### Doll proposal semantics
 
-The RFC mentions Doll proposals (from cloud/mobile instances of a familiar) with `origin.doll_id`, and notes that Doll proposals cannot be Tier 0 auto-promoted into a true familiar. The full specification of Doll proposal semantics — what authority a Doll has, how its proposals are evaluated differently, how the true familiar ratifies or rejects Doll-proposed changes — is future work that intersects with the full Voodoo Doll architecture specification.
+The RFC does not currently specify Doll proposals. Dolls (cloud/mobile instances of a familiar) are a Coven architectural concept, and the intended semantics — that a Doll proposal carries an origin discriminator identifying its source, and cannot be Tier 0 auto-promoted into a true familiar — are not yet in any normative text. The full specification of Doll proposal semantics — what authority a Doll has, how its proposals are evaluated differently, how the true familiar ratifies or rejects Doll-proposed changes — is future work that intersects with the full Voodoo Doll architecture specification.
 
 ### Audit log format standardization