Appendix U · Digital companion · all tools

The Public Accounting Technology Stack

Appendix U: The Public Accounting Technology Stack

Public accounting can begin with paper, notebooks, receipts, photographs, and spreadsheets. It does not require expensive technology at the start. A citizen with a dated note, a stamped copy, and a clear complaint is already more powerful than a citizen who only has memory. But as the work grows, technology becomes necessary. Records must be stored, searched, protected, compared, updated, audited, and published. Without a disciplined technology stack, public accounting can collapse under its own evidence.

The purpose of this appendix is to define a practical technology architecture for public accounting, for reform teams, universities, local governments, citizen groups, legal aid clinics, journalist networks, diaspora teams, professional bodies, and public agencies that want to build public ledgers without creating chaos, privacy breaches, political manipulation, or another unusable portal.

One standard governs the stack: technology must make rights more usable, records more reliable, and power more answerable.

Start With the Process, Not the Software

The first mistake is to buy or build software before defining the process. A broken service does not become accountable because it has an application. A missing record does not become true because it is digitized. A bad workflow with a dashboard is still a bad workflow. The first step is always to define the public duty, the record required, the evidence standard, the privacy rule, the responsible office, the timeline, the appeal route, and the remedy.

• Technology should answer these questions:
• What record are we collecting?
• Who can submit it?
• Who verifies it?
• Who can view it?
• Who can correct it?
• What personal data must be protected?
• What public data can be published?
• What status categories will be used?
• What deadline applies?
• What remedy is being tracked?
• If these questions are unclear, the technology will only automate confusion.

The Minimum Viable Stack

• A public accounting project can begin with a minimum viable stack. It does not need a complex platform immediately.
• A basic stack may include:
• A secure folder system for documents.
• A spreadsheet or database for tracking cases.
• A standard intake form.
• A complaint or claim template.
• A timeline template.
• A privacy assessment form.
• A public dashboard or summary page.
• A backup system.
• A correction log.
• An access control list.

This is enough for a 90-day pilot. The goal is not to impress anyone with software. The goal is to create reliable records and follow-up.

Data Categories

Every system should classify data before collection. Not all data should be treated the same. Some records are public by nature. Some are private. Some are sensitive. Some can be published only in aggregate.

• Suggested categories:
• Public record.
• Internal working record.
• Claimant personal data.
• Sensitive claimant data.
• Medical data.
• Child-related data.
• Family or inheritance data.
• Worker retaliation-risk data.
• Police complaint data.
• Legal case data.
• Financial or tax data.
• Anonymized public data.
• Aggregate public data.

Each category should have access rules. Public records may be widely shared. Sensitive claimant data should be restricted. Medical and child data should be protected strongly. Aggregate data can often reveal public failure without exposing individuals.

Data Fields

• A good public accounting system depends on consistent fields. If every volunteer records information differently, comparison becomes impossible.
• Common fields should include:
• Case or record number.
• Issue category.
• Location.
• Date received.
• Responsible office or institution.
• Claimant reference.
• Privacy level.
• Evidence type.
• Status.
• Deadline.
• Official response.
• Remedy requested.
• Remedy status.
• Next follow-up date.
• Reviewer.
• Correction history.

These fields make the ledger searchable and comparable. A system that cannot show all delayed cases, all missing receipts, all unresolved wage claims, or all stockout complaints is not yet a useful public accounting system.

Unique Record Identifiers

Every case, complaint, record request, project, stockout, wage claim, inheritance safeguard, service delay, or media follow-up entry should have a unique identifier. This prevents confusion when names, locations, or issue descriptions are similar.

• A simple identifier may include:
• Project abbreviation.
• Year.
• Issue category.
• Sequential number.
• For example:
• WAGE-2026-001.
• WARD-2026-014.
• HOSP-2026-009.
• INHERIT-2026-003.
• POLICE-2026-021.
• The identifier should appear on every document, folder, status update, and follow-up note related to the case.

Intake Forms

Intake forms should be simple. If a form is too complex, citizens will avoid it or volunteers will complete it inconsistently.

• An intake form should collect:
• Name or protected reference.
• Contact method.
• Issue category.
• Location.
• Date issue began.
• Responsible person or institution.
• What was owed.
• What happened.
• Evidence available.
• Receipt or tracking number, if any.
• Urgency.
• Retaliation risk.
• Consent level.
• Remedy requested.
• The form should be available in paper and digital versions. Citizens without internet access should not be excluded.

Evidence Upload Rules

• If digital evidence is uploaded, the system should require basic metadata.
• For each uploaded file:
• File name.
• Source.
• Date received.
• Type of evidence.
• Case identifier.
• Privacy level.
• Whether public use is permitted.
• Whether redaction is required.
• Verification status.

A photograph of a broken drain is different from a patient's medical record. A public project board is different from a woman's inheritance document. The system must know the difference.

Status Categories

• Every ledger needs standardized status categories. Vague statuses such as "in progress" can become another fog.
• Suggested status categories:
• Received.
• Under review.
• Evidence incomplete.
• Awaiting claimant response.
• Official notice sent.
• Awaiting official response.
• Official response received.
• Referred to legal aid.
• Referred to authority.
• Resolved.
• Partly resolved.
• Rejected with reasons.
• Disputed.
• Delayed.
• Escalated.
• Closed.
• Closed due to safety risk.
• Closed due to claimant withdrawal.
• Each status should have a date. A case that remains "under review" for months is not being managed.

Deadline Tracking

A public accounting system must track deadlines. Every service timeline, official response period, appeal deadline, committee report date, court date, wage settlement date, stock replenishment date, or project completion date should be recorded.

• The system should show:
• Deadline date.
• Responsible person or institution.
• Deadline type.
• Status.
• Reminder date.
• Missed deadline reason.
• New deadline, if any.
• Deadline history.
• Deadlines make delay visible. A system without deadlines becomes an archive of frustration.

Privacy Levels

• Every case should receive a privacy level at intake and before publication.
• Suggested privacy levels:
• Public.
• Public after redaction.
• Aggregate only.
• Anonymized case summary.
• Restricted internal access.
• Legal review required.
• Do not publish.
• High-risk claimant.

The privacy level should be reviewed if circumstances change. A worker who initially agreed to public use may later face threats. A woman claiming inheritance may need protection after family pressure begins. A patient may withdraw consent. The system must allow privacy decisions to change.

Redaction Rules

• Redaction means removing or hiding personal or sensitive information before sharing a document publicly.
• Redact:
• Names of vulnerable claimants.
• Addresses.
• Phone numbers.
• Identity numbers.
• Medical details.
• Children's names.
• Bank details.
• Signatures.
• Exact locations in sensitive cases.
• Family details not necessary for public issue.
• Witness identities where risk exists.

Do not rely on casual cropping. Redaction should be done in a way that cannot be easily reversed. The original should be stored securely, and the redacted copy should be clearly marked as redacted.

Access Control

• Not everyone working on a project should see everything. Access should follow role and need.
• Possible roles:
• Intake volunteer.
• Case reviewer.
• Legal reviewer.
• Data manager.
• Communications lead.
• Project coordinator.
• External auditor.
• Public viewer.
• Sensitive case reviewer.

Each role should have defined permissions. An intake volunteer may enter basic information but not download sensitive files. A communications lead may see anonymized summaries but not raw medical records. A legal reviewer may access full documents for specific cases. This reduces the risk of leaks and misuse.

Audit Logs

• A system should record who accessed, changed, uploaded, deleted, or exported data. This is especially important for sensitive cases.
• Audit logs should show:
• User.
• Action.
• Date and time.
• Record affected.
• Old value and new value where appropriate.
• Reason for change where required.
• Without audit logs, internal misuse may be impossible to trace.

Correction Log

• Errors will occur. A correction log should record every correction made to a public or internal entry.
• The correction log should include:
• Record identifier.
• Original entry.
• Corrected entry.
• Reason for correction.
• Person requesting correction.
• Person approving correction.
• Date corrected.
• Whether public correction was issued.
• A public accounting system must be able to correct itself with dignity.

Public Dashboard

• A public dashboard should show aggregate answerability without exposing vulnerable people. It should be simple enough for citizens to understand.
• A dashboard may show:
• Number of cases received.
• Cases by issue category.
• Cases resolved.
• Cases pending.
• Average response time.
• Records requested.
• Records received.
• Records missing.
• Deadlines missed.
• Wage amount claimed and recovered.
• Medicine stockout days.
• Service delay patterns.
• Ward complaints resolved.
• Police complaints acknowledged.
• Public project board compliance.
• Female-heir safeguards applied.

The dashboard should avoid long prose inside tables. Use short labels, numbers, percentages, and status categories. Put explanation in paragraphs below the dashboard.

Open Data

Where data is safe and lawful, public accounting projects should publish open data. This allows journalists, researchers, citizens, and officials to analyze patterns.

• Open data should be:
• Anonymized.
• Structured.
• Downloadable.
• Documented.
• Updated.
• Licensed for public use where appropriate.
• Accompanied by methodology.
• Protected against misuse.

Not all data should be open. Sensitive data must remain protected. The principle is openness for public duties, privacy for vulnerable people.

Search and Retrieval

As records grow, search becomes essential. A public accounting archive should allow users to find records by issue, location, date, office, status, deadline, and remedy.

• Search fields may include:
• Issue category.
• Institution.
• District or ward.
• Date range.
• Status.
• Record type.
• Evidence type.
• Privacy-safe keyword.
• Responsible authority.
• A movement that cannot retrieve its own records will eventually lose memory.

Document Naming Standard

Files should be named consistently. Bad file names create confusion.

A good naming format:

CaseID_Date_DocumentType_Source_PrivacyLevel

Examples:

WAGE-2026-001_2026-06-15_MessageScreenshot_Worker_Restricted

WARD-2026-014_2026-06-18_ProjectBoardPhoto_Public

HOSP-2026-009_2026-06-20_Prescription_Redacted

INHERIT-2026-003_2026-06-21_MutationRecord_Restricted

Consistent naming saves time and prevents accidental disclosure.

Backups

• Public accounting records should be backed up. A single laptop, phone, or account should not hold the only copy.
• Backup rules:
• Maintain at least two backups.
• Keep one backup separate from the main system.
• Encrypt sensitive backups where possible.
• Test restoration.
• Control who can access backups.
• Do not back up sensitive data into insecure personal accounts.
• Records that disappear cannot protect claimants.

Security

• Security does not need to be perfect to begin, but basic discipline is essential.
• Minimum security practices:
• Strong passwords.
• Two-factor authentication.
• Separate personal and project accounts.
• Restricted access to sensitive folders.
• Encrypted storage for sensitive data where possible.
• No sharing passwords.
• Remove access when volunteers leave.
• Avoid public Wi-Fi for sensitive uploads where possible.
• Review access logs.
• Train users against phishing.
• A public accounting project can be attacked, infiltrated, or casually compromised. Security is claimant protection.

Offline Access

Technology must not exclude citizens without smartphones, literacy, internet, or digital confidence. Every digital system should have an offline or assisted route.

• Offline options:
• Paper intake forms.
• Help desk entry.
• Telephone intake where safe.
• Community clinic assistance.
• Printed claim templates.
• Physical receipt books.
• Public notice boards.
• Ward meeting records.
• A digital republic that excludes the poor is not a republic but a portal for the already capable.

Language Access

• Public accounting tools should be available in the languages citizens use. Technical English or legal jargon can become another barrier.
• Language access should include:
• Local-language forms.
• Plain-language explanations.
• Audio guidance where helpful.
• Visual guides.
• Examples.
• Volunteer translation.
• Careful translation review.
• Translation should preserve meaning, not merely words. A poorly translated form can mislead claimants.

Artificial Intelligence Use

• Artificial intelligence can help public accounting, but it must be used carefully.
• Useful applications include:
• Summarizing non-sensitive documents.
• Classifying issue categories.
• Drafting first versions of complaints.
• Translating public documents.
• Detecting duplicate records.
• Identifying deadline misses.
• Analyzing aggregate trends.
• Preparing public summaries.
• High-risk uses include:
• Legal conclusions.
• Medical judgments.
• Sensitive personal data processing.
• Identity verification.
• Predicting claimant credibility.
• Automated publication.
• Unverified accusations.

The rule holds: artificial intelligence can assist public accounting, but human review must control public claims, legal interpretation, privacy, and safety.

Data Quality Review

• Every public accounting project should review data quality regularly.
• Ask:
• Are fields complete?
• Are dates accurate?
• Are issue categories consistent?
• Are privacy levels assigned?
• Are duplicate cases merged?
• Are evidence types labeled?
• Are official responses recorded?
• Are deadlines updated?
• Are closed cases truly closed?
• Are corrections logged?
• Bad data can create false conclusions. Data quality is an ethical issue, not just a technical one.

Verification Workflow

• Before any finding is published, it should pass through a verification workflow.
• The workflow may include:
• Initial intake.
• Evidence check.
• Privacy assessment.
• Official response request where safe.
• Legal or technical review where needed.
• Draft finding.
• Internal review.
• Correction of errors.
• Publication decision.
• Follow-up date.
• This workflow prevents the movement from confusing speed with accuracy.

Public Report Generator

• A mature system can generate periodic public reports from the ledger.
• Reports may include:
• Monthly ward report.
• Hospital medicine stock report.
• Wage recovery report.
• Service guarantee performance report.
• Police complaint access report.
• Media follow-up report.
• Public project board compliance report.
• Inheritance safeguard report.
• Court delay report.
• Each report should include methodology, limits, aggregate data, key findings, official responses, remedies, and next steps.

Citizen Notification

Citizens who submit claims should receive status updates where possible. A public accounting project should not reproduce the silence it criticizes.

• Status updates may include:
• Claim received.
• Evidence reviewed.
• More information needed.
• Notice sent.
• Official response received.
• Referred to legal aid.
• Published anonymously.
• Resolved.
• Closed.
• Next follow-up date.
• Even if the system cannot solve the case, it should not leave the claimant in darkness.

Integration With Official Systems

• Where reform-minded public bodies exist, public accounting tools can integrate with official systems. This should be done carefully.
• Integration can include:
• Complaint submission.
• Status verification.
• Public service data.
• Hospital stock data.
• Ward complaint data.
• Project records.
• Procurement records.
• Court delay data.
• Police complaint acknowledgment data.

But integration should not allow officials to delete citizen records, identify vulnerable claimants unnecessarily, or suppress independent findings. Civic systems and official systems can cooperate while maintaining safeguards.

Technology Governance

• A public accounting platform should have governance rules.
• Governance should define:
• Who owns the data.
• Who controls access.
• Who approves publication.
• Who handles correction requests.
• Who responds to legal notices.
• Who protects claimant privacy.
• Who manages backups.
• Who audits the system.
• Who can shut down or archive the project.
• If governance is unclear, technology can become a power struggle.

Vendor and Platform Risk

• If a project uses outside vendors or commercial platforms, it must consider risk.
• Ask:
• Where is the data stored?
• Who owns it?
• Can the vendor access sensitive records?
• Can data be exported?
• What happens if subscription ends?
• What security protections exist?
• Can the vendor be pressured?
• Does the tool comply with local privacy law?
• Can records be deleted accidentally?
• Do not place sensitive claimant data into tools whose terms, security, or ownership are unclear.

Public Archive

Some records should become part of a long-term public archive. Public reports, redacted records, official responses, public datasets, methodologies, forms, and correction logs should be preserved.

• The archive should be:
• Searchable.
• Backed up.
• Organized by issue and date.
• Protected from tampering.
• Open where safe.
• Clear about corrections.
• Public memory needs infrastructure. Without archives, every generation starts again.

Sunsetting and Closure

• Projects may end. A responsible project should plan for closure.
• Closure plan should include:
• Notify claimants where relevant.
• Export records.
• Secure or delete sensitive data.
• Archive public materials.
• Transfer active cases where possible.
• Publish final status.
• Remove user access.
• Preserve correction mechanism for public reports.
• A project that ends without data care may harm claimants and destroy evidence.

Implementation Levels

• Public accounting technology can grow in levels.
• Level one: paper forms, folders, spreadsheet.
• Level two: shared secure storage, standardized forms, status tracker.
• Level three: database, role-based access, dashboards, correction logs.
• Level four: public portal, anonymized open data, automated reminders, official response tracking.
• Level five: integrated public accounting platform with audit logs, privacy controls, record requests, public dashboards, and independent verification workflows.
• Do not jump to level five before level one works. Complexity should follow proven process.

Example Stack for a 90-Day Pilot

• A 90-day pilot can use:
• Paper intake forms.
• A spreadsheet with controlled access.
• Secure folder storage.
• Unique case identifiers.
• A privacy assessment column.
• A deadline tracking column.
• A public summary document.
• A monthly report.
• A correction log.
• This is enough to start. The pilot's success depends more on discipline than software.

Example Stack for a University Clinic

• A university clinic may use:
• Case management database.
• Role-based student access.
• Faculty review queue.
• Document storage with privacy levels.
• Official notice templates.
• Deadline reminders.
• Anonymized dashboard.
• Public report generator.
• Data quality review schedule.
• Consent records.
• The clinic must train students before giving them access to sensitive material.

Example Stack for Local Government

• A ward-level local government system may use:
• Complaint intake portal.
• Physical complaint desk.
• Receipt number generator.
• Service category routing.
• Response timelines.
• Status dashboard.
• Maintenance schedule tracker.
• Project board registry.
• Contractor performance log.
• Public ward scorecard.
• Citizens should be able to file both digitally and physically.

Example Stack for Hospital Medicine Stock

• A hospital stock system may use:
• Pharmacy inventory database.
• Patient-facing availability board.
• Stockout log.
• Outside purchase record.
• Complaint tracker.
• Equipment functionality tracker.
• Official fee display.
• Monthly public dashboard.
• Procurement delay tracker.
• Privacy-protected patient complaint module.
• The system should connect stock data to patient experience, not only internal inventory.

Example Stack for Police Complaint Access

• A police complaint system may use:
• Complaint reception register.
• Acknowledgment printer or receipt book.
• Written non-registration reason form.
• Senior review tracker.
• Vulnerable complainant flag.
• Misconduct complaint route.
• Aggregate station dashboard.
• Privacy and safety controls.
• The first technology requirement: every complaint gets a number.

Risks of Technology

• Technology can create new risks.
• Possible risks include:
• Data leaks.
• False precision.
• Exclusion of poor citizens.
• Manipulated dashboards.
• Automated denial.
• Overcollection of personal data.
• Vendor dependency.
• Political surveillance.
• Loss of human judgment.
• Public shaming through searchable data.
• Portal without remedy.
• A technology stack must be designed against these risks from the beginning.

The Digitalization Trap

The digitalization trap occurs when institutions use technology to look reformed while citizens still cannot claim rights. A portal that says "under process" forever is not reform. A dashboard with old data is not transparency. A digital land record without correction route is not justice. A hospital stock system hidden from patients is not patient accountability. A police database that records complaints internally but gives citizens no acknowledgment is not access.

Technology is useful only when it changes the citizen's power.