[PERSPECTIVE P01: RFC 0051 refs table is a typed directed graph that DynamoDB single-table design cannot query natively]
The `refs` table defines 8 semantic edge types (support, oppose, refine, address, resolve, reopen, question, depend) across 5 entity types, creating a typed directed graph with up to 25 distinct edge-pair combinations. DynamoDB's single-table design encodes each ref as `ref#{source_id}#{ref_type}#{target_id}`, which supports forward traversal (given a source, find its targets) but makes reverse traversal ("what supports P0001?") require a GSI or full-partition scan. In a relational database, `SELECT * FROM refs WHERE target_id = 'P0001' AND ref_type = 'support'` is a single indexed query; in DynamoDB, answering "show me the full dependency chain from verdict V01 back through its adopted recommendations, the tensions they address, and the perspectives those tensions depend on" requires multiple sequential round-trips with application-level graph assembly. This is not a theoretical concern -- it is the exact query pattern the verdict entity's `tensions_resolved`, `key_evidence`, and `key_claims` fields exist to serve, and denormalizing those chains into the verdict record is an admission that the graph cannot be traversed at query time.

[PERSPECTIVE P02: PostgreSQL achieves true local-prod parity without Docker overhead via embedded options]
RFC 0058's strongest argument is local-prod parity, but PostgreSQL achieves identical parity through embedded Postgres (pgtemp, pg_embed) or Neon's serverless driver, both running the same wire protocol and query planner as production. The Docker-for-DynamoDB-Local requirement actually introduces a parity gap: DynamoDB Local is a Java-based simulator with documented behavioral divergences (no IAM, no capacity limits, different error codes for throttling), whereas a local PostgreSQL instance runs the identical engine as production.

[TENSION T01: Denormalized verdict fields prove the graph is too expensive to traverse in DynamoDB at query time]
The verdict entity pre-computes `tensions_resolved`, `recommendations_adopted`, `key_evidence`, and `key_claims` as JSON arrays because reconstructing these relationships from the refs table in DynamoDB would require unbounded sequential reads -- but this denormalization creates a write-amplification and consistency problem that a relational JOIN solves at read time with zero duplication.

---