Add witness observations co-signed by a paired peer's own device key

[ChelseaKR]

What

A neighbour saw the ceiling collapse; a fellow tenant smelled the gas. Today their account can only be typed into the tenant's timeline as an Other entry with no independent binding. Add a witness observation record: a paired peer (already authenticated by sync pairing) writes a short statement and optional captures on their own device, signs it with their device key, and sends it as a sealed delta; the case owner's vault commits it into custody as a distinct record type with the witness key fingerprint, and the packet renders it as "observation recorded by another device (fingerprint), not by the tenant". The witness keeps a signed copy.

Why it matters

Corroboration is the record-strength assessment's strongest factor (strength.py), and the project already has instrument corroboration (sensor.py) and partner capsules (capsule.py), but not a person on another device. Pairing gives a key without an identity system, which matches the no-accounts principle. This is presentation and custody, never a legal claim: the packet must not call it testimony, and the copy is held to the same "not legal advice" boundary as letters.

Scope

• A record type in model.py and evidence.py; a sync message; a verifier decision-table row; a strength factor.
• CLI witness add|export; the app flow on the witness side; EN/ES copy.
• Disclosure policy: witness fingerprint and statement included, witness device metadata stripped.

Out of scope

• Identity verification of the witness.
• Notarisation or any legal-form language.

Done when

• A witness record from a paired device verifies with its signature; a modified statement fails.
• A witness record from an unpaired key is refused at merge.
• The packet shows the record under a distinct heading with the fingerprint and the "not testimony" boundary text present in both languages.

Pointers

• src/habitable/pairing.py, src/habitable/sync.py, src/habitable/evidence.py, src/habitable/strength.py, src/habitable/capsule.py, docs/verifier-decision-table.md, docs/sharing-trust-model.md

Proposed with AI assistance.

[ChelseaKR]

Triage: buildable, well specified, and left for a dedicated pass.

Five-check against origin/main @ bf631af: git grep -i witness origin/main -- src/habitable returns nothing — no witness record type, no sync message, no strength factor, no decision-table row. The substrate it names is all present: src/habitable/pairing.py, sync.py, evidence.py, strength.py, capsule.py and docs/sharing-trust-model.md are on main. Premise holds.

This is one of the better-specified issues in the backlog — the done-when criteria are all testable, and the design instinct is right: pairing already yields an authenticated device key without an identity system, so a co-signed observation adds corroboration without adding accounts.

Left for a builder rather than started here, with two notes worth having before someone does:

• The copy boundary is the risky part, not the crypto. A signed statement from a paired device is straightforward; a packet that a reader interprets as testimony is the failure. The issue is right that it must render as "observation recorded by another device (fingerprint), not by the tenant", and that text is subject to the same "not legal advice" boundary as letters, in both catalogs, under the readability gate. Getting the crypto right and the sentence wrong would be a net harm.
• It touches the custody model, the sync protocol and the verifier decision table together, so it is one focused PR with the decision-table row written first — not a partial landing that leaves a record type the verifier does not know how to judge.

Also worth an owner check before building: the strength-factor change. Adding witness corroboration to strength.py changes an assessment a tenant may rely on, and how much a co-signed observation should move it is a judgment, not an implementation detail.

---

Triage pass against origin/main @ bf631af. Verdict only; nothing was changed. Prepared with AI assistance.

[ChelseaKR]

Measured: this is not blocked on additionalProperties: false

This issue was parked behind the packet-format question #313 frames. I measured it rather
than inheriting it, and the answer changes the shape of the block.

Method. docs/packet-bundle.schema.json at main (5d5ad26), validated with
jsonschema 4.26.0 under Draft 2020-12 in a throwaway venv kept out of the repository.
Baseline: all seven committed bundles validated unmutated, so pre-existing errors are
subtracted (packet-v1 missing archive_timestamps, packet-v4's three custody actions
— both #313's, both still present). Then the minimal document mutation this issue's own
Done when demands was applied to tests/golden/packet-v4/bundle.json (the richest
corpus member: 2 items, 1 artifact, 1 relationship, 1 v3 timeline entry, 13 custody
entries) and the error set diffed against the baseline.

Two controls fired, so the probe can return a rejection: adding kind to a v3 timeline
entry is refused by that object's not/required guard, and a non-string value in
custodyEntry.details is refused by its additionalProperties: {"type": "string"}.

Verdict for #300: the one genuinely blocked issue of the six — and it is blocked in three places.

This is the only one of the six that needs a new property on a closed object in its
natural shape, and the third rejection below is the one that matters most, because it is not
an enum you can widen — it is a const.

shape	validates?	what refuses it
witness observation carried as an artifact with the witness key fingerprint	no	/$defs/artifact is additionalProperties: false, so witness_fingerprint is rejected; and artifact.artifact_type has no witness_observation value — two independent refusals on the same object
timeline entry pointing at the witness record via links.witness_entry_id	no	/$defs/timelineEntryV3/properties/links is additionalProperties: false
that same link reusing the existing links.capture_ids array	yes	—
a witness entry declaring its own custody action, integrity.custody_action: "witness_added"	no	/$defs/timelineEntryV3/properties/integrity fixes custody_action to "const": "note_added"
the whole witness record on item.witness or on timelineEntryV3.witness	yes	both parents are additionalProperties: true

So, precisely: the object is /$defs/artifact and the property is witness_fingerprint,
with artifact_type needing witness_observation alongside it. That is the answer to
"which object and which property" for this issue.

But the const is the harder half, and it is the one to decide first. A witness
observation can be carried inside the contract as it stands — item.witness validates
today. What cannot be expressed is that it entered custody as something other than a note.
timelineEntryV3.integrity.custody_action admits exactly one value, so a signed
observation from another device and a sentence the tenant typed produce the same custody
action. The Done when turns on exactly that distinction ("a witness record from an
unpaired key is refused at merge"), and a verifier reading only the packet would have no
field to check it against.

Recommendation: do not build the item.witness escape hatch. It would satisfy the
schema and quietly lose the property the feature exists for — a distinct, checkable custody
binding. This one wants the vocabulary decision before code.

The general correction, for all six

additionalProperties: false on seven objects is not what holds this set. Every one of
the six has a shape that validates against the published schema exactly as it stands today,
because item, issue, timelineEntryV3 (top level), custodyProof, timestampToken,
appendix, scope, handoffManifest, signature and the document root are all
additionalProperties: true.

What actually rejects is the closed vocabularies — and those are on a different axis
from object closedness, which is why naming the seven closed objects does not describe the
constraint:

vocabulary	where	closed object?
custodyEntry.action	8 values	yes
artifact.artifact_type	13 values	yes
relationship.relationship_type	11 values	yes
workflowIntegrity.custody_action	2 values	yes
timelineEntryV3.integrity.custody_action	const — one value	yes
timelineEntryV3.event_type	9 values	no, the object is open
timelineEntryV3.source	6 values	no, the object is open
timestampToken.kind	2 values	no, the object is open
item.record_kind	2 values	no, the object is open

And the two are not the same kind of breakage, which is the part worth settling once:

• A new optional field on an open object is invisible to a consumer following the rule
  docs/bundle-schema.md already states — "consumers must ignore unknown fields". It costs
  nothing and needs no version bump.
• A new enum value cannot be ignored. The published schema itself rejects the packet, so
  a third party who pinned the $id fails on a document this code considers valid. That is
  the same failure additionalProperties: false produces, arrived at from the other
  direction, and it is where five of these six touch the contract. The machinery that
  already exists for it is packet_version plus the verifier's forward rejection.

So the decision the six are really waiting on is "may a feature mint a new custody action /
artifact type / relationship type inside packet_version 4, or does that need 5?" — not
"should the seven objects be reopened?". Only #300 needs a new property on a closed
object, and even #300 is reachable without one.

Reproduction script (not committed): the mutation set and its two controls are in the
campaign scratch as probe_six.py; every number above is from a run of it.

Prepared with AI assistance; reviewed before submission.