# Research — Inventory Dependencies Graph (042)

This document resolves all implementation clarifications for the MVP and records the key decisions with rationale and alternatives.

## Decisions

### 1) Pagination vs limit-only
- Decision: **Limit-only** (no pagination/cursors in MVP).
- Rationale: Pagination introduces cursor semantics, UI states, sorting guarantees, and additional tests; MVP goal is fast/stable/testable.
- Alternatives considered:
  - Add pagination now: rejected due to complexity and low MVP value.

### 2) Edge limits in UI
- Decision: **50 per direction** (inbound and outbound), so up to **100 total** when showing both directions.
- Rationale: Keeps each query bounded and predictable; matches existing UI composition (combine inbound + outbound).
- Alternatives considered:
  - 50 total across both directions: rejected because it makes results direction-dependent and less intuitive.

### 3) Relationship-type filter (UI)
- Decision: Add **single-select Relationship filter** with default **All**; persists in querystring.
- Rationale: Small UX improvement with high usefulness; minimal risk.
- Alternatives considered:
  - No relationship filter: rejected (spec requires it; improves scanability).

### 4) Unknown/unsupported reference shapes
- Decision: **Warning-only** (no edge created).
- Rationale: Creating “missing” edges for unknown shapes is misleading; it inflates perceived missing prerequisites and reduces trust.
- Alternatives considered:
  - Create missing edge: rejected as potentially inaccurate.

### 5) Where warnings are stored
- Decision: Persist warnings on the **sync run record** at `InventorySyncRun.error_context.warnings[]`.
- Rationale: Auditable, debuggable, no new schema, consistent with “observable automation”.
- Alternatives considered:
  - Per-item warnings in `InventoryItem.meta_jsonb`: rejected (pollutes inventory, harder to reason about run-level issues).
  - New warnings table: rejected (migrations/models/retention/cleanup burden).

### 6) Foundation object typing
- Decision: For `target_type='foundation_object'`, always store `metadata.foundation_type`.
- Rationale: Deterministic UI labeling/resolution; avoids inference.
- Alternatives considered:
  - Infer foundation type from relationship type: rejected (brittle).

## Notes / Implementation Implications

- If the current code path creates missing edges for unknown assignment shapes, it must be adjusted to **warning-only** to match spec.
- Warning payload shape should be stable: `{type: 'unsupported_reference', policy_id, raw_ref, reason}`.