| # 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. |
|
|
