- clarify BEDS is compliance-friendly architecture, not certification - add healthcare/regulated deployment framing to visual brief - document controls BEDS provides vs contract implementation responsibilities - update wiki index description for regulated-deployment positioning
2.3 KiB
2.3 KiB
BEDS — Back End Data System
Developer Wiki
Welcome to the BEDS developer wiki. This is a living document. It grows with the codebase and should be updated whenever a design decision is made, a pattern is established, or a component is implemented.
If you are reading this as a new contributor, start here and read in order. The origin story is not fluff — it explains why BEDS is built the way it is, and understanding the why is the difference between extending the framework correctly and breaking it subtly.
Table of Contents
Foundation
- Origin Story — Where BEDS came from and why it was built
- Architecture Overview — The full system design and its principles
- The Four Nodes — appServer, admin, segundo, tercero — roles and responsibilities
Operations
- IPL — Initial Program Load — The bootstrap sequence, step by step, and why order matters
- Configuration System — Layered TOML, environment files, topology options
- Modernization Roadmap — POC-first execution sequence and modernization requirements
- Architecture Visual Brief — Leadership-facing architecture narrative, diagram prompts, and regulated-deployment positioning
Messaging
- Queue Topology — AMQP exchanges, queues, routing keys, and the broker model
Notes
- Design Notes & Discussions — Spew/no-nazi-twitter concept, open questions, architecture discussions in progress
Data
- Template System — REC and REL templates, the TLA convention, schema-as-contract
- Event Lineage — Compound event IDs, parent/child relationships, depth tracking
Reference
- Glossary — Terms, abbreviations, and conventions used throughout BEDS
Contributing to This Wiki
- Write for the programmer who inherits this code after a two-week handoff with no knowledge transfer
- Document decisions, not just mechanics — why matters more than what
- Dated history entries belong in source code comments, not here — the wiki covers concepts, not changelogs
- When you change the system, update the wiki in the same commit