Public case study
PDIG
A local-first personal dependency and digital-infrastructure graph across native platforms.
Status Specification and design. Not a contact manager — a dependency graph over personal infrastructure.
What it is
PDIG (Personal Digital Infrastructure Graph) is a specification and design: it models the dependencies between a person’s accounts, devices, credentials and services as one computable graph.
It is not a contact manager — the nodes are infrastructure, not people. It is also unrelated to the Broad Institute’s DepMap project; the shared name implies no connection.
Why it matters
A dependency graph answers a question an inventory cannot: not “which accounts do I have” but “if this provider disappears, what breaks, and in what order”.
A complete map of a person’s infrastructure is a high-value target, so the design constraint is that the graph stays on the user’s own devices — no hosted account system, and no server assumed to be reachable.
Current public status
Specification and design. The canonical model, the conformance-suite plan, the repository and cryptographic layers, and the per-platform native UI decisions are defined.
No implementation has been released and there is no public repository.
What is publicly available
Nothing to open today. This page is the specification’s only public account.
Notes
The specification is the artefact. Anything describing an implementation is design intent, not completed work.
Implementation status
Spec-level work. No public artifact to inspect.
What exists today, and how you would check it. Nothing below is a rendered mockup of something that does not exist.
- Public code
- None — nothing published
| Component | State | Note |
|---|---|---|
| Canonical specification | Designed | A single graph model for personal infrastructure — accounts, devices, credentials, providers, domains — plus the invariants that keep two implementations comparable. |
| Conformance harness | Not public | A fixture-based conformance suite is reported, including impact-correctness checks against hand-worked expected results. The author reports 64 fixtures; nothing is published, so this site cannot check the count. |
| Android native implementation | Not public | Reported as the most complete platform target. No build, screenshot or test output is public. |
| Native migration plan | Designed | Moving spec primitives out of scripted layers and into native code is specified as a migration step, not completed. |
| Cryptography and privacy rules | Designed | Local-first storage with explicit handling of secrets and derived keys. Design only — no audit is claimed. |
| iOS / HarmonyOS targets | Planned | Adapter work not started publicly. |
| Public repository | Not public | None. This page is the only artifact. |
How to read these states 3
- Designed Specified — architecture, contracts and scope exist in writing.
- Planned Identified for future work. Nothing to inspect yet.
- Not public Reported to exist, but no public artifact can be checked.
Why the specification comes first
The bet is that a written spec with testable invariants is the scarce artifact — native clients are downstream of it. Nothing here asserts that the clients exist in any checkable form.
Source Author design notes.