Skip to content

Latest commit

 

History

History
46 lines (34 loc) · 4.17 KB

File metadata and controls

46 lines (34 loc) · 4.17 KB

PRD — Evolith Tracker · Artifacts (v1.0)

Bilingual: Español Status: Baseline · Date: 2026-07-05 · Owner: Product

1. Purpose & Scope

The Artifacts bounded context governs the lifecycle of every artifact and evidence record produced across the five Phase Gates — the durable, auditable proof that each gate was legitimately passed. It inherits canonical artifact definitions from Evolith Core (Conformist), produces artifact instances locally, validates them against Core-approved schemas, and captures immutable evidence that ties each gate decision to the concrete deliverable that justified it. Its reason to exist in the Tracker is auditability: it is the append-only spine of end-to-end traceability from initiative to release.

2. Functional Requirements

Each requirement is capability-level; acceptance is stated as an outcome, not a task.

  • REQ-ART-01 — Definition sync from Core. The Tracker keeps a local, cacheable mirror of Core-approved ArtifactDefinitions, refreshed at startup and on demand via the Core BFF Gateway. Acceptance: the latest Core-approved schemas are available for validation; stale caches are flagged and reads remain available (fail-open) when Core is unreachable.
  • REQ-ART-02 — Artifact instance submission. Any authorized user or agent can submit an ArtifactInstance bound to a definition and an initiative. Acceptance: every submission is validated against its Core schema before acceptance; a submission is only recorded as VALID when it conforms.
  • REQ-ART-03 — Schema validation with field-level feedback. Submissions are checked against the definition's Core schema with actionable, field-level results. Acceptance: a rejected submission returns a field-level error report identifying which rules failed and why.
  • REQ-ART-04 — Validation report. A detailed, rule-by-rule validation report is available for any submitted artifact, valid or invalid. Acceptance: the report shows each schema rule's outcome (pass/fail) and the failing value where applicable, and is exportable as JSON.
  • REQ-ART-05 — Evidence record linking. An immutable EvidenceRecord can be linked to a VALID ArtifactInstance and to the gate decision it justifies. Acceptance: each gate decision has concrete evidence traceable to a specific artifact version, queryable from the gate audit trail.
  • REQ-ART-06 — Evidence immutability & audit. Once captured, evidence is write-once and tenant-scoped. Acceptance: evidence cannot be mutated after write, and all access is RLS-enforced and auditable.
  • REQ-ART-07 — Evidence chain traceability. The ordered evidence trail (Initiative → PhaseGateState → ArtifactInstance → EvidenceRecord) is navigable and inspectable for any gate decision. Acceptance: the full chain renders with per-node type, version, author, timestamp and status; broken or missing links are detected and flagged.
  • REQ-ART-08 — Audit-grade export. Evidence and artifacts are exportable as portable, verifiable packages for compliance. Acceptance: a chain export (signed PDF) and an initiative-level evidence package (ZIP of VALID artifacts + evidence + signed manifest with hashes) are produced and their generation is logged.

3. Governance Touchpoints

  • All five Phase Gates. This context is the Customer of every gate: it receives ArtifactInstance and EvidenceRecord payloads as gate work completes.
  • Gate evaluation (Supplier to Governance). PhaseGateState references EvidenceRecord IDs to authorize gate transitions; a gate cannot be legitimately passed without traceable evidence.
  • Evidence & audit. Provides the append-only evidence chain and audit-grade exports consumed by compliance and audit reviews.
  • Metrics. Evidence timestamps feed lead-time / DORA computations in the Metrics context.

4. Non-Goals

This PRD is deliberately at Initiative and capability altitude. It does not decompose into epics, user stories, tasks, sprints or story points. That execution-level granularity lives in external tools (e.g. Jira / Azure DevOps), outside Evolith.

5. References