MediaWiki · Information Architecture · Correspondence Classification · Records Management · Knowledge Management
A lightweight personal correspondence and records-control system created in Germany from early 2022, combining a custom four-part classification code with MediaWiki to organize administrative letters by subject domain, source/location, year, month, and a short human-readable description.
1. Project Overview
This project was a lightweight correspondence registry and personal records-management system created in Germany from early 2022.
The problem was practical:
Administrative letters from different authorities, organizations, landlords, medical providers, lawyers, and other sources needed a consistent way to be classified and understood quickly.
Instead of relying on:
- inconsistent filenames,
- long folder names,
- memory,
- or manually browsing through many PDF files,
I designed a compact coding system and adapted MediaWiki as the searchable registry layer.
The system was intentionally simple.
Its goal was not to reproduce a full enterprise DMS.
Its goal was:
Fast Classification
+
Fast Recognition
+
Fast Retrieval
2. Core Classification Format
The reference structure was:
[CATEGORY] / [SOURCE] / [YY] / [MM]
Example:
6/CRS/26/09
The code communicates four independent dimensions:
WHAT DOMAIN?
↓
CATEGORY
WHERE FROM?
↓
SOURCE / LOCATION
WHEN?
↓
YEAR + MONTH
Then a short text explains the exact subject.
3. Meaning of Each Segment
3.1 Category Code
The first number represents the subject domain of the correspondence.
The system contains 12 predefined subject categories.
Known examples include:
1 = Lawyers / BAMF / similar legal or immigration-related authorities
2 = Housing / Rent / Landlord / accommodation-related matters
3 = Health / medical-related matters
...
12 = another predefined subject domain
The categories from 4 to 12 existed in the original scheme but are intentionally not reconstructed here because their exact historical definitions have not yet been provided.
The important design principle is:
The first number classifies what type of administrative matter the letter belongs to.
It is not:
- a serial number,
- a sequence number,
- or a unique document ID.
4. Source / Location Code
The second segment is a three-letter identifier.
Example:
CRS
This is used to represent the source, location, authority, institution, or administrative origin associated with the correspondence.
The idea was to create a compact code that could be recognized quickly without writing the full organization name every time.
Conceptually:
Celle / Residenzstadt
↓
CRS
The exact three-letter abbreviations were part of the user-defined filing vocabulary.
5. Year and Month
The final two components encode time:
26 = 2026
09 = September
So:
6/CRS/26/09
means:
- subject category 6,
- source/location code CRS,
- year 2026,
- month September.
This creates immediate chronological context.
6. Short Description
The classification code is followed by a short plain-language description.
The description was intentionally kept very short—typically around ten words or less.
Example concept:
6/CRS/26/09
Residence-related administrative letter
or:
2/XYZ/24/11
Rent increase notification
The code answers:
What category?
Where from?
When?
The short description answers:
What exactly is it?
7. Important Design Boundary
The code itself was not intended to uniquely identify every single letter.
It was a classification key.
Several letters could theoretically share the same:
Category
Source
Year
Month
because uniqueness was not the goal.
The goal was filing context.
This distinction is important.
8. Information Architecture
The system can be represented as:
LETTER
│
┌──────────────┼──────────────┐
│ │ │
↓ ↓ ↓
SUBJECT DOMAIN SOURCE TIME
1–12 3-letter YY/MM
│ │ │
└──────────────┼──────────────┘
↓
6/CRS/26/09
↓
Short Description
This is essentially a faceted classification model.
9. Why the Model Was Effective
Administrative correspondence usually becomes messy because several dimensions are mixed together.
For example:
Residence Letter September.pdf
Rent New.pdf
Health Scan 2.pdf
Lawyer Final Final.pdf
The custom coding scheme separated the dimensions.
Instead of embedding everything into a filename, the system encoded the structure consistently.
Benefits included:
- predictable classification,
- easier recognition,
- faster retrieval,
- compact references,
- chronological grouping,
- source grouping,
- subject grouping,
- and reduced naming inconsistency.
10. Twelve Subject Domains
The first layer of the system was thematic.
Known examples:
Category 1
Legal / immigration-related correspondence, including lawyers, BAMF, and similar authorities.
Category 2
Housing-related correspondence, including rent, landlord, accommodation, and related matters.
Category 3
Health-related correspondence.
Categories 4–12
Predefined in the original personal filing scheme, but their exact definitions are not reconstructed here without source confirmation.
This preserves accuracy.
11. Classification Before Software
The strongest part of the project was designed before MediaWiki entered the picture.
The process was:
Define the information model
↓
Define the categories
↓
Define source/location abbreviations
↓
Define time encoding
↓
Define short description rule
↓
Choose software
Only then was MediaWiki used as the implementation layer.
12. MediaWiki as the Registry
MediaWiki was installed and adapted as the lightweight registry interface.
The goal was not to create a complex document-management platform.
MediaWiki was used because it already provided:
- editable pages,
- search,
- browser access,
- simple linking,
- revision history,
- and low operational overhead.
The classification scheme remained independent of the software.
13. Minimal Data Model
A typical registry entry contained only:
Classification Key
+
Short Description
Example:
6/CRS/26/09
Administrative correspondence regarding residence status
This intentionally avoided large forms.
14. Why the System Stayed Minimal
A system that requires too much maintenance eventually stops being used.
The project therefore avoided unnecessary fields such as:
- long notes,
- complex status tracking,
- workflow stages,
- dozens of tags,
- duplicate metadata,
- or manual full-text summaries.
The design principle was:
Capture only enough information to find and understand the correspondence later.
15. Secretariat-Inspired Design
The system was inspired by the logic of a formal administrative secretariat.
Conceptually:
Incoming Correspondence
↓
Classify
↓
Assign Filing Context
↓
Write Short Note
↓
Retrieve Later
The result was a personal registry with organizational discipline.
16. Accounting-Style Coding Influence
The coding model also borrowed from accounting and administrative coding systems.
Instead of relying purely on names, the system used stable structural codes.
That created:
- compact references,
- predictable patterns,
- lower ambiguity,
- and easier scanning.
17. What the Code Encodes
The code is effectively a compressed metadata record.
For example:
6/CRS/26/09
contains:
Subject Domain → 6
Source → CRS
Year → 2026
Month → September
Then one short human-readable sentence adds context.
18. Human-Readable + Structured
The design deliberately combined:
Structured Metadata
+
Human Meaning
The code is compact and systematic.
The description is readable.
Neither replaces the other.
19. Daily Workflow
The actual workflow was intentionally fast:
Receive Letter
↓
Identify Subject Category
↓
Identify Source / Location
↓
Encode Year
↓
Encode Month
↓
Create Classification Key
↓
Write ≤10-word Description
↓
Save / Register in MediaWiki
This made the system realistic for repeated personal use.
20. Example Workflow
Suppose a letter arrives in September 2026 from a Celle administrative source represented as CRS.
The workflow becomes:
Subject Category → 6
Source Code → CRS
Year → 26
Month → 09
Result:
6/CRS/26/09
Then:
Short description:
Administrative residence correspondence
The full meaning is immediately visible.
21. Search and Retrieval
The registry could be searched through several dimensions.
Search examples:
CRS
to find entries associated with that source,
or:
26/09
to identify a period,
or keywords from the short description.
This made the MediaWiki layer useful even though the classification system itself was simple.
22. Temporal Organization
Embedding year and month directly into the key gave each entry an immediate time context.
For example:
/22/03
/23/11
/24/06
/26/09
This supported chronological browsing without additional metadata.
23. Source Vocabulary
The three-letter source identifier created a controlled vocabulary.
Instead of repeatedly writing full names such as:
City Administration ...
Immigration Office ...
Insurance Company ...
Law Office ...
the system could use short stable codes.
This reduced typing and naming variation.
24. Stability of the Schema
The classification format remained stable:
CATEGORY / SOURCE / YEAR / MONTH
New letters did not require redesigning the system.
New sources only required new three-letter codes.
New years and months naturally fit the same model.
25. Extensibility
The scheme could grow without structural change.
Example:
1/ABC/22/02
2/XYZ/23/07
3/MED/24/11
6/CRS/26/09
The meaning of each segment remained consistent.
26. No Artificial Serial Number
The historical system did not append:
/001
/002
/003
because uniqueness was not the purpose.
A serial number would have solved a different problem.
The original goal was:
classification, not database identity.
If a future version needs uniqueness, a separate internal ID can be added.
27. Separation Between Filing Key and Unique ID
A modern implementation could preserve:
6/CRS/26/09
as the human-facing classification key while using:
UUID
or:
Database ID
internally.
This avoids damaging the original information model.
28. Personal Administrative Context
The system was used for personal administrative correspondence in Germany beginning in early 2022.
It was not presented as:
- an enterprise records system,
- a government registry,
- or a legally certified DMS.
It was a personal production system designed to impose order on increasingly complex correspondence.
29. Why MediaWiki Fit the Problem
MediaWiki was a pragmatic choice because the core need was:
Simple Entry
+
Search
+
Editing
+
Reference
A custom Laravel or Java application would have been unnecessary for the original scope.
This is an example of choosing a sufficiently capable existing platform instead of overengineering.
30. Build-vs-Buy Decision
The project demonstrates an important engineering principle:
Build the classification model; reuse the platform.
Custom work was focused on:
- taxonomy,
- codes,
- process,
- and information structure.
Generic capabilities such as editing and search were delegated to MediaWiki.
31. Lightweight DMS Interpretation
The project can reasonably be positioned as a lightweight DMS / correspondence registry.
It supported:
- classification,
- indexing,
- human-readable context,
- and retrieval.
It did not implement:
- OCR,
- full workflow automation,
- digital signatures,
- retention schedules,
- enterprise RBAC,
- or legal records-management compliance.
That boundary should stay explicit.
32. What the Project Demonstrates
The strongest skills demonstrated are:
- information architecture,
- taxonomy design,
- classification systems,
- records organization,
- process simplification,
- knowledge management,
- platform customization,
- pragmatic software selection.
33. My Role
The project was designed and implemented end-to-end.
Responsibilities included:
- designing the 12-domain classification scheme,
- defining the meaning of the first category number,
- creating three-letter source/location codes,
- defining year/month encoding,
- defining the short-description rule,
- installing MediaWiki,
- adapting MediaWiki to the registry use case,
- and using the system operationally.
34. Technology Stack
Confirmed:
- MediaWiki
- browser-based registry
- custom classification architecture
- manually maintained source-code vocabulary
The exact historical:
- PHP version,
- database version,
- MediaWiki version,
- hosting stack,
have not been specified and should not be invented.
35. Portfolio Positioning
Recommended title:
MediaWiki Correspondence Registry & Classification System
Recommended subtitle:
Information Architecture · Records Management · MediaWiki · Administrative Filing
36. Portfolio Classification
Primary:
- Information Architecture
- Knowledge Management
- Records Management
Secondary:
- MediaWiki
- Administrative Systems
- Document Control
- Personal Information Management
37. CV Relevance
Recommended:
Tier C — Supporting Portfolio Evidence
It is useful for demonstrating:
- structured thinking,
- taxonomy design,
- process simplification,
- pragmatic platform use.
It should not displace stronger application architecture or production marketplace projects from the main CV.
38. Career Evidence
This project supports evidence of:
- Information Architecture
- Taxonomy Design
- Document Classification
- Records Management
- Knowledge Management
- Process Simplification
- Platform Customization
- Practical System Design
39. Website Hero
MediaWiki Correspondence Registry
Information Architecture · Records Management · MediaWiki · Correspondence Control
Designed a compact four-part filing scheme for German administrative correspondence, encoding subject domain, source/location, year, and month, then adapted MediaWiki into a lightweight searchable registry using short human-readable descriptions.
40. Website Project Card
MediaWiki Correspondence Registry
MediaWiki · Classification · Records Control
Created a lightweight correspondence registry using a custom 12-domain classification model, three-letter source codes, year/month encoding, and short searchable descriptions.
41. Short Website Card
Correspondence Registry
A MediaWiki-based personal records system using structured subject/source/year/month codes to classify German administrative correspondence.
42. One-Line Description
Designed a compact four-part correspondence classification scheme and used MediaWiki as a searchable registry for German administrative records.
43. CV Entry
MediaWiki Correspondence Registry — Information Architecture / Records Management
Designed and operated a lightweight correspondence registry from 2022 using MediaWiki and a custom four-part filing code: subject category, source/location, year, and month. The system used 12 predefined subject domains and short human-readable descriptions to organize personal administrative correspondence with minimal maintenance overhead.
44. Short CV Entry
Designed a MediaWiki-based administrative correspondence registry using 12 subject categories, source codes, and year/month classification.
45. Interview Story
Situation
Administrative correspondence in Germany was growing across multiple domains such as legal/immigration matters, housing, health, and other categories.
Ordinary file naming became increasingly inconsistent.
Task
Create a simple filing model that could identify:
- what type of matter a letter belonged to,
- where it came from,
- and when it belonged.
Action
I created a four-part classification code:
CATEGORY / SOURCE / YY / MM
The first field represented one of twelve predefined subject domains.
The second used a three-letter source/location abbreviation.
The final fields encoded year and month.
Each entry then received a short description in MediaWiki.
Result
The system created a consistent and low-maintenance correspondence registry without requiring a custom DMS.
46. Technical Interview Version
“I had increasing administrative correspondence in Germany and did not want to depend on random filenames or deep folder structures. I first created a taxonomy of twelve subject domains. For example, category 1 covered lawyers, BAMF and related legal or immigration authorities; category 2 covered housing and rent; category 3 covered health-related correspondence. Then I added a three-letter source/location code plus two digits for year and two for month. A reference like
6/CRS/26/09immediately tells me the subject bucket, source, and period. Under that I write only a very short description. MediaWiki then acts as the searchable registry. The useful part was the information model—not the complexity of the software.”
47. Architecture Lesson
The project demonstrates:
Information architecture should precede implementation.
The classification model was the real system.
MediaWiki was simply the runtime interface.
48. Simplicity as a Design Goal
The project deliberately optimized for low maintenance.
The operational rule was:
One Code
+
One Short Description
This minimized friction.
A more complex system might have looked more sophisticated but would have been slower to maintain.
49. Modern V2 Possibility
A V2 could automate the same workflow without changing the human-facing model.
Possible flow:
Upload Letter
↓
Extract Sender / Date
↓
Suggest Category
↓
Suggest Source Code
↓
Generate Filing Key
↓
Suggest Short Description
↓
User Confirms
↓
Save
The original classification scheme can remain unchanged.
50. V2 Data Model
A modern minimal data model could be:
Correspondence
├── id
├── category_code
├── source_code
├── year
├── month
├── short_description
├── file_path
└── created_at
Optional fields:
document_date
sender
external_reference
tags
51. V2 Category Table
A modern implementation could represent the 12 categories explicitly:
Category
├── code
├── name
└── description
Known examples:
1 → Legal / Immigration / Lawyers / BAMF
2 → Housing / Rent / Landlord
3 → Health / Medical
The remaining categories should only be added after historical confirmation.
52. V2 Source Table
Source codes could also be standardized:
Source
├── code
├── full_name
├── city
└── notes
This would preserve the compact three-letter syntax while making the vocabulary easier to maintain.
53. V2 Search
Modern search could support:
category = 2
source = CRS
year = 2026
month = 09
keyword = rent
while still showing the original compact reference:
2/CRS/26/09
54. V2 OCR
Optional OCR could help extract:
- document date,
- sender,
- reference number,
- subject.
But OCR should remain an enhancement, not the foundation of the system.
The filing taxonomy remains the central design.
55. V2 AI Assistance
A modern assistant could suggest:
- category,
- source code,
- short description.
But final classification should remain deterministic and user-confirmed.
Example:
Detected sender: Stadt Celle
Suggested source: CRS
Suggested category: 1
Suggested description: Residence permit correspondence
56. V2 Uniqueness
If unique document identity is required in a software implementation:
Internal UUID
should be used.
Do not turn:
6/CRS/26/09
into something it was never designed to be.
That code should remain a human classification key.
57. Evidence Boundaries
Safe to claim:
- system created from early 2022,
- MediaWiki installed and adapted,
- 12 subject-domain categories,
- category 1 includes lawyers/BAMF/similar matters,
- category 2 includes housing/rent-related matters,
- category 3 includes health-related matters,
- three-letter source/location code,
- two-digit year,
- two-digit month,
- short description,
- personal administrative use,
- classification key rather than unique document ID.
Do not claim:
- exact definitions of categories 4–12 until confirmed,
- enterprise deployment,
- OCR,
- AI classification,
- automated workflow,
- legal records-management compliance,
- unique serial numbering,
- complex relation graphs.
58. Final Portfolio Statement
From early 2022, I designed and operated a lightweight personal correspondence registry for German administrative documents using MediaWiki and a custom four-part classification scheme. The first field represents one of twelve subject domains—for example legal/immigration, housing/rent, or health—followed by a three-letter source/location code, a two-digit year, and a two-digit month. A code such as
6/CRS/26/09therefore captures subject context, origin, and period, while a short human-readable description explains the specific correspondence. The project intentionally focused on simple, sustainable records control rather than unnecessary DMS complexity.
59. One-Line Summary
A MediaWiki correspondence registry built around a custom 12-domain subject classification plus source/year/month coding for German administrative records.
60. Ultra-Short Portfolio Label
MediaWiki Correspondence Registry — Classification · Information Architecture · Records Control