# Design the evidence records and source register

## Purpose

This guide provides a practical data model for a personal evidence garden. It can be implemented in Markdown, a spreadsheet, a database or a private website.

The model separates three things that are often collapsed:

1. what happened;
2. what the available sources establish;
3. what the episode may suggest about the person’s capabilities.

## Record types

### Evidence episode

A bounded piece of work, judgement, responsibility or problem-solving that can be described and reviewed.

### Source

A document, artefact, public link, third-party statement or explicit recollection used to support or contextualise an episode.

### Lead

A potentially useful activity or claim that has not yet been developed into a sufficiently clear episode.

### Question or retrieval view

A practical route into several records, such as “How has this person made complex material usable?” It does not create new evidence.

## Recommended episode schema

```yaml
id: EP-001
title: Plain, recognisable episode title
status: draft | reviewed | approved-for-use | archived
summary: Short account of what the episode demonstrates
context: Period, setting, organisation and relevant constraints
problem: The difficulty, decision, need or opportunity
contribution: What the person personally noticed, decided, made or changed
connection: How that contribution related to the wider work or outcome
outputs:
  - Tangible output, delivery, decision or result
capability_links:
  - Provisional capability or recurring contribution
source_ids:
  - S01
confidence: high | mixed | recollection-led
gaps:
  - Important uncertainty or missing attribution
confidentiality: private | anonymisable | public
notes: Additional review information
```

The fields can be simplified. The important distinctions are contribution, outcome, provenance and uncertainty.

## Recommended source schema

```yaml
id: S01
title: Original filename or descriptive source title
source_type: report | proposal | email | website | testimonial | recollection | other
date: Known date or approximate period
location: File path, URL or archive reference
what_it_adds: The specific facts or context supplied by this source
limitations: What the source does not establish
confidentiality: private | anonymisable | public
linked_episode_ids:
  - EP-001
```

## Stable identifiers

Identifiers should remain stable when titles, topics or status change.

A simple convention is sufficient:

- `EP-001` for evidence episodes;
- `S01` for sources;
- `LD-001` for undeveloped leads;
- `Q01` for retrieval questions.

Maintain an ID register. Never reuse an identifier after deleting or merging a record. If two records are combined, retain a note explaining which ID was retired and where its material moved.

## Evidence strength

Avoid a single numerical evidence score. Different sources establish different aspects of an episode.

A source may support:

- **existence:** the project or output existed;
- **association:** the person was involved;
- **contribution:** the source identifies what the person did;
- **scale:** dates, markets, participants, budget or reach;
- **outcome:** an observable result is documented;
- **interpretation:** the source helps explain why the work mattered.

A proposal may strongly support problem framing and planned method while providing no evidence that the project was delivered. A final report may establish the work and outputs but say little about individual contribution. A recollection may explain decisions that no formal document recorded.

## Attribution rules

Use the narrowest claim supported by the material.

- A named team member is not automatically the sole author.
- A company result is not automatically an individual result.
- A proposed activity is not a delivered activity.
- Participation does not establish leadership.
- A project description does not establish every method was personally performed.
- Repeated autobiographical text is one account reused, not several witnesses.

When contribution remains unclear, record the project as a lead or describe the known association without upgrading it to a stronger claim.

## Capability links

Capability links are interpretations, not raw facts. They should be traceable to activities in the record.

Prefer links such as:

- reframing an ambiguous problem;
- integrating evidence from several disciplines;
- making a specialist method usable for clients;
- coordinating work across professional boundaries;
- designing a decision process under uncertainty.

These are more informative than broad adjectives. Even so, they should remain provisional until similar patterns appear elsewhere.

## Review states

- **Draft:** extracted or reconstructed but not yet reviewed by the person concerned.
- **Reviewed:** corrected for factual accuracy and attribution.
- **Approved for use:** suitable for a specified external purpose, possibly with anonymisation.
- **Archived:** retained for provenance but no longer used as an active record.

Approval should be purpose-specific. A record may be accurate enough for private reflection but unsuitable for a public portfolio because of confidentiality.

## Minimal Markdown template

```markdown
# EP-001: Title

**Status:** Draft  
**Confidentiality:** Private  
**Sources:** S01, S04

## Summary

## Context

## The problem

## Personal contribution

## How the work connected

## Outputs and traces

## Possible capability links

## Gaps and uncertainty
```