# Methodology

## Principle

The knowledge base must be reproducible from the Bundestag DIP API.  No political promise or status claim is invented by the application.

## Data sources

The application uses the DIP REST API endpoints for:

- proceedings (`vorgang`),
- procedure positions (`vorgangsposition`),
- parliamentary printed papers (`drucksache` and `drucksache-text`),
- plenary protocols (`plenarprotokoll` and `plenarprotokoll-text`),
- activities (`aktivitaet`),
- persons (`person`).

The app stores raw JSON in JSONL format and a normalized CSV for the dashboard.

## Evidence versus promise status

A DIP record can show that a legislative procedure, document, activity, or debate exists.  It does not by itself prove that a campaign or coalition promise is completed.  The manual tracker therefore has a separate `reviewed_status` field.

Recommended labels:

- `Completed`: evidence directly shows that the promised legal or administrative action was completed.
- `In progress`: formal steps exist, but implementation is not complete.
- `Not started`: no relevant evidence has been found.
- `Broken`: evidence shows reversal, abandonment, or a missed deadline.
- `Needs human review`: evidence is relevant but insufficient for a status decision.

## Auditability

For every fetched record, keep:

- DIP resource type,
- DIP ID,
- API URL,
- PDF URL where returned,
- retrieval timestamp,
- raw API JSON.