capabilities.md

Capability and claim ledger

Current as of: 2026-08-22. CI verifies every local evidence path below.

This is the short, current source for what habitable may honestly claim. Automated tests show that a code path behaves as asserted under synthetic fixtures; they do not prove legal admissibility, real-world safety, usability, accessibility conformance, or fitness for a tenant's case. Dated research, audit, and roadmap documents remain useful context, but this ledger controls when their historical wording differs from current code.

Status vocabulary:

• Shipped — implemented on main with a directly linked automated test.
• Partial — implementation exists, but the named gap limits the claim.
• Planned — no usable implementation exists on main.
• Externally unvalidated — implementation and automated evidence exist, but the outcome requires independent human or domain review that has not happened.

Capability	Status	Current claim	Evidence	Explicit gap
Encrypted local vault and sealed originals	Partial	Persistent case state, custody data, device identity, sync policy, originals, and consolidated primary/additional/archive timestamp-token sidecars are encrypted at rest; original reads re-check SHA-256 fixity. Legacy plaintext token JSON migrates after unlock by publishing and verifying encrypted state before repeatable cleanup. Token operations are anchored to a no-follow directory descriptor and fail if that directory is swapped. Browser uploads and packet sanitization use random, owner-only files in a short-lived OS temporary workspace outside the vault. Normal five-blob state saves stage and flush a complete generation, publish behind a recovery journal, and roll back prepared or clean up committed transactions on the next open.	token-sidecar adversarial tests, vault tests, atomic-save crash tests, crypto tests, temporary-workspace tests, app staging tests	Sidecar AEAD protects locked-vault confidentiality/integrity, not timestamp authenticity; exported tokens remain public and require TSA verification. Stable hashed filenames leak capture-id equality/linkability, ciphertext length approximates token volume, and filesystem mtime/ctime expose update timing; there is no padding or filesystem-metadata hiding. Platforms without descriptor-relative directory mkdir/scan/open/no-follow-stat/unlink/rename support are unsupported for the whole vault: create and open fail closed. config.toml remains plaintext, including TSA names/URLs and user-edited policy/template values. Decoded media and unlocked tokens exist in process memory; unlinking is not secure erasure, so legacy blocks, crash remnants, swap, snapshots, or storage forensics remain endpoint risks. Atomic replacement/directory fsync depend on the host filesystem; concurrent processes are not transaction-isolated. An unlocked endpoint, malware, media failure, or a compelled passphrase can expose or destroy data.
Media and instrument capture	Shipped	Still images, audio/video, and supported sensor CSV files enter the same seal, hash, timestamp-token, and custody pipeline.	media tests, sensor tests	Sensor interpretation is deliberately narrow; source authenticity and what media depicts are not proven.
Signed packet export and standalone verification	Partial	Whole-unit packet v4 directories contain a signed bundle, policy-processed shared media, custody-bound artifacts and relationships, versioned profiles, optional handoff views and originals, HTML/PDF renderings, and independently verifiable records; packet v1–v3 compatibility remains executable. Custody identities are omitted from the public chain while its salted actor commitments remain verifiable. A profile's review can expire: selecting an already-expired one is refused, and an export whose selected profile expired since selection falls back to no profile — disclosed by name and reason in bundle.json and every rendering — instead of presenting stale guidance.	packet tests, workflow tests, atomic/fail-closed export tests, golden compatibility tests, golden corpus, tamper-evidence battery, challenge spec, seal ADR, profile-expiry ADR	Issue/date-scoped exports are blocked because packet v4's complete custody proof can expose excluded record identifiers. Identity-bearing custody export is unsupported: its retained compatibility setting is rejected before output. Review-dependent workflows remain marked external_review_required. The producer key ships with the packet, so its signature alone does not establish a real-world producer identity, and an attacker who rewrites bundle.json, rebuilds the custody chain, and re-signs with a fresh key passes every signature check. What constrains that is the packet seal: an RFC 3161 token over the SHA-256 of the whole bundle, so one signature the producer's device cannot mint covers every narrative field, every shared_hash (the images a reader actually opens), and the custody head. A seal that is present is always checked against the bundle in front of it, so a retained, foreign, or malformed seal fails with nothing asserted. An absent seal, and one from an authority the recipient never anchored, are reported rather than fatal until --require-packet-seal is passed: no field inside a rewritable bundle can stop an attacker deleting the seal, and making an unanchored seal fatal would leave a producer who sealed with an unfamiliar authority worse off than one who never sealed. Two residuals are measured, not asserted away: a packet exported offline has no seal at all, and an attacker who can obtain a token from an authority the recipient anchors can re-seal a rewritten bundle — they cannot backdate it, so --seal-not-after <the date you received it> catches that, and without that flag it is a documented miss. Producer identity remains out of reach without an out-of-band anchor; --expected-producer-key serves recipients who have one. No external party has attempted to break a packet.
Offline CRDT case merge and encrypted transport	Shipped	Explicitly paired peers can converge case state after offline edits. Pairing is signed, recipient-sealed, and case-bound; v2 messages bind the expected sender, recipient, case, and replay identifier before merge. Relay/local-mailbox payloads are encrypted. The optional relay rejects retained state above fixed per-room and aggregate room/message/byte caps without silent eviction or binding the rejected candidate's TOFU state; a bounded global-cap retry may only remove independently TTL-expired room/token state. Bounded startup validation applies the same caps to opt-in journals, rejects far-future timestamps, repairs unterminated tails before a later acknowledgement, and cleans a separately bounded exact crash-temp namespace; /healthz reports a startup_replay state so a refused journal is never rendered as an idle relay, /readyz refuses when an unknown amount of at-rest ciphertext went unread, and the access log records the status actually written rather than a presumed 200.	sync tests, sync security tests, sync fail-closed corpus, relay resource tests, pairing ADR	People must compare the displayed peer fingerprint through an independent channel. A compromised authorized endpoint can still disclose plaintext, and a relay can observe timing and volume metadata. Relay persistence is not an fsync-backed delivery guarantee or secure erasure, assumes one local writer per persistence directory, and has no dedicated Windows CI lane. Process peak memory also includes one bounded request body, streaming buffers, Python/runtime overhead, and bounded journal decoding beyond retained ciphertext. The sync adversarial corpus stores malformed field mutations re-applied to a genuinely signed message, not committed sealed envelope bytes (which would require committing a recipient private key), so it pins the decoder's validation order rather than freezing the encoder's output. A refused journal directory is reported, not repaired: the ciphertext stays on disk unreferenced and recovery is a documented manual operator step. Live-state counts describe process memory only and include TTL-expired messages not yet swept.
Recipient-sealed organizer sharing	Partial	A paired tenant can seal a full-case share to the organizer's exact key; the unit metadata field may be omitted, and an untrusted courier sees ciphertext.	sharing tests, trust model	Issue-subset shares are blocked before message construction because sync v2's complete source-custody proof can expose identifiers from excluded issues. Omitting one metadata field is not anonymization: case identifiers, descriptions, custody identifiers, or original media metadata can still identify the unit. A versioned scoped/rehashed custody-view protocol is not yet implemented.
Browser app, EN/ES catalogs, and PWA assets	Shipped	The local browser client presents a condition-first Repair Trail with separate Reported and Secured dates, a tenant-statement/checkable-proof fold, keyboard-safe entry dialogs, follow-up actions, and an explicit tenant-copy/review-copy boundary. It has English/Spanish catalog parity and includes installable PWA assets in source and built wheels.	app-server tests, accessibility tests, dialog keyboard tests, i18n tests, PWA tests	This is a locally served web app, not a signed native app-store package. Preparing or creating a copy does not transmit it.
Python package build and publishing automation	Partial	CI builds and smoke-tests the wheel, and tagged releases are wired to PyPI Trusted Publishing with OIDC.	CI workflow, release workflow, release guide	PyPI requires one-time external pending-publisher/environment setup, and repository configuration alone is not evidence that a release successfully published.
Key lifecycle and threshold recovery	Shipped	Passphrase/DEK rotation (including encrypted token sidecars), recovery blobs, and threshold-share recovery have automated round-trip and failure tests.	token-sidecar rotation tests, vault rotation tests, threshold tests	Recovery ceremonies and storage practices have not been validated with a tenant organization. DEK rotation's final multi-file swap is not fully transactional; staging can transiently double token-directory entries, and SIGKILL debris requires manual recovery.
Reference importer and signed receipt example	Shipped	The contrib importer verifies packet inputs and can emit a signed, digest-bound receipt.	importer tests, contrib guide	It is a reference integration, not a supported legal-aid case-management connector.
RFC 3161 token and authority trust	Partial	Capture can obtain or defer RFC 3161 tokens, and verification checks the imprint and CMS signature. A chain is called trusted only when a verifier is given an accepted certificate anchor, and that anchor rule is a documented one-hop check (habitable.tsa.ANCHOR_RULE): the anchor must be the token's signing certificate or the certificate that directly issued it. A real public authority's token, anchored offline to that authority's own published root, is pinned by a committed fixture.	TSA tests, real-authority anchor tests, golden fixture provenance, token property invariants, trusted-certificate CLI test, verifier guide	Without an explicit trusted certificate, a cryptographically valid token is not independently authority-anchored. Do not collapse “token valid” into “authority trusted.” An RFC 3161 CMS wrapper carries bytes outside its signature, so a byte change there is not necessarily rejected. What the property suite pins — exercised both with a synthetic certificate anchor configured and with none — is that no mutation moves the attested time or digest, and that no mutation can manufacture trust. Trust is losable, not forgeable: editing the embedded signing certificate breaks the anchor match and drops a trusted_chain from true to false, so a trusted verdict can be destroyed by tampering but never created by it. The anchor rule is not X.509 path validation: intermediates are never discovered, so a root two hops above the responder does not chain (DigiCert's published root, for example, does not; its timestamping CA certificate does), and certificate validity periods, basic constraints, key usage including id-kp-timeStamping, name constraints, and revocation are not checked. openssl ts -verify -CAfile does build a path and can therefore succeed where this check declines; the difference is documented in verifier-decision-table.md §5 rather than reconciled. Only one public authority (FreeTSA, which issues its responder directly from its published root) is exercised end to end; authorities that chain through an intermediate remain untested against their published roots because that shape is not supported.
Issue timeline	Shipped	Timeline 2.0 entries use reviewed event/source choices, separate reported occurred_at from device recorded_at, link captures/notices/delivery/responses, reopen the same issue on recurrence, and commit the semantic payload into signed local custody. Packet v3 verifies the commitment and renders it in EN/ES without reinterpreting v1/v2 fields.	Timeline v3 tests, migration contract, packet schema	Timeline events are not RFC 3161 timestamped. Occurrence and source remain human assertions; a legacy migration's later custody binding is labelled as such, and no completed recipient/legal review establishes fitness or truth.
Automated accessibility coverage	Partial	The app and HTML packet have automated axe checks; the app also has keyboard, dialog focus-return, and 320 px reflow tests. packet.html is the designated accessible packet rendering.	app axe tests, keyboard/dialog/reflow tests, HTML packet tests, accessibility ADR	No recorded human NVDA/VoiceOver pass exists. The PDF is not tagged PDF/UA, and automated checks are not a WCAG conformance determination.
Repair-request letter generator	Partial	habitable letter turns logged issues into a dated repair-request/notice letter (accessible HTML + PDF) with jurisdiction-aware framing only, a configurable cure period, a standing "not legal advice" disclaimer, and per-union wording overridable in config.toml. Its evidence sentence is gated on there actually being captures: with none it states that no photographs are attached and makes no packet offer.	letter tests, CLI letter tests, design and assumptions	English only. Every generated string is an English literal; the letter is emitted with lang="en" whatever the vault's configured language, and habitable letter prints the unmet request in the requested language. A legal-register Spanish translation is deliberately not machine-generated: it needs a Spanish-speaking legal-aid reviewer first, so this is an open gap for Spanish-speaking unions, not a closed decision. Wording and delivery workflow have had no legal review or pilot; the letter asserts no statute, and any citation comes from union-supplied config. It is correspondence, not proof — the checkable record is the packet.
Building-level evidence roll-up (campaign)	Partial	An organizer who already holds the keys to several unit vaults can roll up each vault's own already-computed state — captures, awaiting timestamps, custody verdict — into a building view, and optionally export one combined multi-unit packet. Computing a roll-up writes nothing to any vault and creates no new store.	campaign tests, implementation	It reads only vaults whose keys the operator already legitimately holds; it is not a directory, a server, or a way to reach a case you were not given. UnitHealth.export_ready is a vault-level "nothing known to block starting an export" signal computed without building a packet, so it is not, and must not be read as, verify's evidence_ready verdict about packet contents. No pilot has used it on a real building.
Opt-in aggregate commons (commons)	Partial	A union can deliberately compute a k-anonymous, on-device aggregate summary of housing conditions and choose whether to publish the resulting file. The module imports only the standard library and the local case model, and has no network capability.	commons tests, implementation	Nothing runs in the background or on a timer, and nothing is transmitted anywhere by the tool — publication is a separate human act. A k-anonymity threshold bounds re-identification within one summary; it does not defend against an adversary combining several published summaries, external datasets, or knowledge of a specific building. No statistical disclosure review has been done.
Fixed-question building patterns (pattern)	Partial	One organizing question, answered locally: filters on the device, coarsens dates to ISO weeks, applies the commons household threshold, and emits no household identifiers or network traffic.	pattern tests, implementation	Deliberately one fixed question, not a query interface; the coarsening and threshold are the whole privacy argument and carry the same multi-release limitation as the commons row. Not reviewed by a statistician or used in a real campaign.
Partner evidence capsules (capsule)	Partial	A small signed evidence capsule can be produced for, and conservatively imported from, a partner organization; imports enter the same artifact/custody path as any other captured item.	capsule tests, implementation	A capsule signature establishes that a key signed those bytes, never that the partner organization is who they claim to be or that their contents are accurate — key distribution and partner identity are out of band and unsolved here. No partner organization has used it.
Evidence-strength assessment	Partial	The local assessment reports observable technical factors such as timestamp status, authority count, and corroborating timeline entries.	assessment tests, implementation	It does not score truth, admissibility, legal weight, or likelihood of winning.
Duress/decoy vault	Planned	A limits-first design decision exists; there is no duress, panic, or decoy implementation.	ADR 0007, current threat model	A coerced unlock reveals the real vault. No safety benefit from a decoy may be claimed today.
Signed native mobile/desktop package	Planned	Native packaging is a roadmap item only.	roadmap	The current PWA/local-server flow is not a signed App Store, Play Store, MSIX, DMG, or equivalent package.
Tagged PDF/UA packet	Planned	The project deliberately uses packet.html as the designated accessibility rendering until an open tagging path exists.	accessibility ADR, ACR	The PDF has selectable text and metadata but no PDF/UA structure tree.
Independent legal/court/inspector fitness	Externally unvalidated	Packets are technically structured and independently checkable; legal and forum usefulness are hypotheses awaiting review.	legal-review brief, pilot brief	No completed legal review, court validation, inspector validation, or admissibility finding exists. Do not call the product or packet “court-ready.”
Independent security and cryptographic assurance	Externally unvalidated	Threat models, tests, and review materials exist for an external audit.	auditor brief, audit status	No independent security/cryptographic audit has been completed.
Human accessibility and language usability	Externally unvalidated	Automated EN/ES and accessibility checks provide a baseline suitable for human evaluation.	manual test protocol, accessibility tester brief	No recorded human screen-reader pass or human Spanish accessibility review has been completed.
Tenant/organizer workflow and recovery usability	Externally unvalidated	Synthetic demos and workshop/pilot materials exist.	pilot brief, workshop guide	No real tenant-union or legal-aid pilot has been completed; use remains synthetic-only while alpha.