ReportLog
We will email a one-time code to confirm the address. That address becomes the administrator, and this is the only time this screen is offered.
Shown on every page, in the browser tab, on the lock screen and in the emails this deployment sends. This archive needs its own name — the software is called ReportLog either way, and the footer keeps saying so.
Report"Log" gives you the two-tone name
above. Single quotes pick a part out more quietly, in grey:
Munich'Log'. You can use both in one name. The quotes
themselves are never shown, and a name with none in it is one colour.
A starting point, and nothing more than that. Whichever you pick, every single thing it sets stays yours to change afterwards — this fills the settings in for you, it does not lock anything.
Each one also makes a draft logbook: the questions a reporter answers. Nobody can file anything until you have looked it over and launched it, under Admin → Logbooks.
This deployment is not offering any starting points. Skip below and set everything up by hand — nothing is lost, the next screens ask the same questions either way.
This is the site’s own decision, and it is separate from the reporter’s. A report is only ever published if its reporter permitted publication and a moderator approved it and this is on. Either way, reports carry on being filed, confirmed and moderated, and nothing is deleted or hidden from a moderator.
Photos, video, audio and PDF documents. Everything is re-encoded rather than passed through, so camera metadata and location do not survive. You can narrow which kinds later; narrowing never invalidates a file already accepted.
This is whether this deployment stores files at all. Whether any given form asks for them is one of its questions — a logbook takes files if it has a “Photos, video or documents” question, and none if it does not. Saying yes here does not start asking anybody for anything.
Two dials. Palette is every colour on the site. Theme is the lettering, the edges and how wide the page runs, and sets no colour at all. Change either and the frames below change with you; the site takes it when you continue.
Confirmed teal and serious crimson keep their meaning whatever you pick — they are how the site says what it means.
This is the password you just used — the one that keeps this site off the open internet. Whoever installed this deployment chose it and knows it. Decide now whether they should keep being able to get in.
ReportLog
File a report. A moderator reviews it. Once it is filed, nobody — including whoever runs this archive — can alter or remove it without that being visible.
Accepting makes you the owner: you become the only person who can appoint or remove an administrator. Whoever hands it over becomes an administrator.
This deployment has not written its front page yet. An operator replaces this text with what this archive is for and who should file into it.
Anyone can file.
ReportLog
This is a printed copy of the online form. It shows every question, including the ones only some people are asked. To file a report, use the website — a report has to be confirmed by email, which is what lets you see it afterwards, correct it, or withdraw it. A form filled in on paper cannot do any of that.
If you or someone else needs help right now, contact your local emergency services. This form is for documentation, not real-time help.
Version — · printed —
Whoever runs it has closed the form. Reports already filed are unaffected — they are still held, still reviewed, and if you filed one you can still open, correct or withdraw it from your own account.
Nothing here says whether the form will reopen. If you were sent here to file something, the people who sent you are who to ask.
Check your email
Sent to
Your report is not filed yet. Clicking the link in that email is what files it — which is what stops anyone filing a report in your name. After that it waits for a moderator, and the same link shows you its status any time.
Nothing arrives? Check the spam folder before filing again, so the same account does not end up in the record twice.
ReportLog
Every submitted report, in real time.
What has been filed, what was published, and what wasn't — so the filter itself can be checked, not just its output.
Every report has a fingerprint that was computed the moment it was filed and can never be recomputed to a different answer. This page works it out again from the stored report and tells you whether the two still agree.
A report that has been altered since it was filed cannot produce a matching fingerprint. Neither can one that has been inserted into, or removed from, the sequence — each report's fingerprint is built partly from the one before it, so the whole run has to hold together.
You do not have to take this page's word for any of it. It shows you the exact text that gets fingerprinted, so you can run SHA-256 over it yourself and compare. The same information is published daily to several independent public repositories, each protected against rewriting, so altering the record would mean altering all of them at once.
ReportLog
ReportLog
ReportLog
ReportLog
01 · What this is
This deployment has not written its About page yet. An operator says here who runs this archive, why it exists, what it covers and what it will not do, and how to get in touch. The section below — about the software itself, and how to check the record without taking anybody’s word for it — is already written and needs nothing from you.
02 · How it works, briefly
You file a report. A moderator reads it before anybody else does, and decides whether it is published. Nothing appears on the public board until that has happened, and there is no path that skips it.
Once a report is filed it is sealed. It is never edited and never deleted — not by a moderator, not by whoever runs this archive, not by us. A correction is filed as a new version alongside the original, and both stay visible. A report can be withdrawn from public view; the fact that it was withdrawn is itself part of the record.
The section below explains exactly what "sealed" means and how to check it for yourself, without trusting anybody who runs this site.
Part two
Everything below describes ReportLog, the software this archive runs on. It is the same on every deployment, and none of it is written or controlled by whoever runs this one. It is free software, and you can read all of it.
03 · The chain
When a report is filed, its contents are assembled into an object, canonicalized under RFC 8785 and hashed with SHA-256. That hash covers the report’s own reference number, so a report cannot be renumbered afterwards either.
Each report also carries the hash of the report before it in the same logbook. That makes each logbook a chain: changing anything in an old report changes its hash, which breaks every link after it. You cannot quietly alter one entry — you would have to rebuild everything since, and the next section is why that does not work either.
Every logbook is its own chain. A fault in one breaks that one and no other, and each can be downloaded and checked on its own. The first report of a logbook links to a starting value made from the logbook’s name, so a report cannot be moved from one chain to another without it showing.
A field is written into the hashed object only when it applies. An absent field and an empty one are different things, and keeping them different is what allows new optional fields to be added without changing the fingerprint of a single report already filed.
04 · The outside witness
A chain proves internal consistency and nothing more: whoever holds the database could rebuild the whole thing and it would still be self-consistent. So once a day a list of every logbook’s latest link is sent to an independent timestamp authority, which returns an RFC 3161 token — third-party evidence that the record looked exactly like that at that moment.
Once a logbook is on that list it stays on it, and its count of reports can only grow. With separate chains, a whole logbook could otherwise be deleted without any other chain noticing; the list is what notices.
The list and its token are published to a transparency log that is mirrored across several git hosts under different operators. That is not redundancy for its own sake. A record that one company holds is a record that one company can be compelled to remove, and the claim this is all here to support is that nobody — including whoever runs this archive — can quietly alter or suppress it.
The log is never rewritten, not even to correct it. If something is found that invalidates published proofs, that fact is published beside them rather than tidied away.
05 · Checking it yourself
Every published report shows its fingerprint. Anybody can take the report as published, rebuild the object, hash it, and compare. The code that does this on the way in and the code that does it on the way out are held to producing byte-identical objects, and the test suite fails if they ever diverge — because a verifier that agrees with the writer by accident is not a verifier.
Nothing about that check requires this server to be honest, or even to exist. The timestamp tokens are verifiable against the timestamp authority, and the transparency log is public.
06 · Append-only, in the database itself
Eight tables refuse modification at the database level: a trigger rejects UPDATE and DELETE outright. That is deliberately not left to the application, because an application is one bug away from doing the wrong thing and a trigger is not.
TRUNCATE was a real hole in this and is now closed separately, because PostgreSQL does not fire row-level triggers for it. "Append-only" was true of UPDATE and DELETE and was never true of TRUNCATE until somebody checked.
07 · Who can see what
The report itself — what happened, where, when — is what gets published once a moderator approves it.
Who filed it is held separately and encrypted, readable only by a moderator, and keyed to the report thread rather than to a version, so filing a correction does not create a second copy of somebody’s contact details.
Every time a moderator opens a reporter’s identity, or the untouched original of an attached file, that is recorded with the reason they gave. Reporters can see those entries on their own reports, with the reason but never the moderator’s name. Opening the log of who opened what is itself recorded.
08 · Moderation
There is no auto-publish path in the software and there must not be one. A moderator reads every report before it appears.
What a moderator approves and what they refuse is a judgement, and it belongs to whoever runs this archive rather than to the software. A deployment publishes its own moderation standard; if this one has, it is on the Standards page.
09 · The role ceiling
An Access Manager can appoint and remove moderators and can set up organizations. They cannot appoint another Access Manager. That is deliberate: if they could, the role would spread on its own and the ceiling would not be a ceiling.
The rule is asserted in one place, tested, and checked again at the route that would grant the role — two checks rather than one, because this is the sort of thing that is quietly wrong for months.
10 · Where it runs
ReportLog is a Node application, PostgreSQL, and one Linux server. The page loads no fonts, scripts or trackers from anywhere else, so reading this archive does not tell any third party that you did.
Where this particular deployment is hosted, and under which jurisdiction, is the operator’s to state — see the imprint and the privacy policy.
11 · What this deliberately cannot do
It cannot tell you a report is true. It can tell you that a report was filed at a certain time, has not been altered since, and was reviewed by a moderator. Whether what it describes actually happened is a separate question, and the archive does not pretend to answer it.
It cannot prove nothing was omitted. The chain shows that what is here has not been changed. A report that was never filed leaves no trace, and nothing can make it.
It cannot protect somebody who identifies themselves in the text. Identity is held separately and encrypted; an answer that names its own author is published as written.
12 · The source
ReportLog is licensed AGPL-3.0-or-later. Every claim on this page is checkable against the source rather than taken on trust, which is the point of publishing it.
Whoever runs this archive did not write the software and cannot change what it does without publishing that change too. That is what the licence is for.
A deployment publishes its own documents here. Nothing is listed until an operator adds them.
A deployment keeps its own changelog here, written for the people who use the site rather than as a list of commits.
ReportLog
Email and a one-time code — no password, no separate account to create.
ReportLog
Reports tied to your email. Corrections and withdrawals never erase anything — the original stays in the archive either way.
Most of what you submit is public once it's approved. Two things are not: the contact and identity details you gave us, and the untouched original of any photo or video you attached — the one that still has the location and device information in it.
Every time a moderator opens either of those, it's recorded here, with the reason they had to write. We don't show you which moderator. They're volunteers, and naming one to a reporter who is unhappy with a decision puts that person at risk. What you're owed is that it happened, when, and why — and the reason is the part you can actually judge.
This does not include a moderator simply reading your report. That part is public, or about to be.
ReportLog
Choose how you want to hear about new reports.
Which logbooks to hear about. Only published reports are ever sent.
ReportLog
Every report starts pending — mark it valid, invalid, or unknown. Only valid, non-withdrawn reports ever appear publicly. Every decision requires a reason, visible only here.
Links, check-ins and messages sent to this site's lists. Approving one lets it be counted; nothing anybody wrote is ever published. Rejecting is not deleting — the entry stays, it just is not counted.
ReportLog
Accounts collected on paper, over the phone or in person, entered on someone else's behalf. Every one carries the organization it came through and your statement that you transcribed it faithfully.
A batch is a working session, not a record. Enter as many accounts as you like, correct them, then file the whole set in one go. Nothing enters the archive until you say so.
ReportLog
Who files under this organization's name, and how it appears on the reports they file.
Anyone here can file reports under this organization's name. Add them by email — if they have no account yet the invitation waits and attaches the first time they sign in.
They get an email with a link. It says which organization, which role, who invited them and what that role can see — and nothing happens until they open it and agree. The link works once and expires in seven days.
Invitations not yet accepted
There is no decline button — ignoring an invitation is how somebody says no — so silence is the only signal you get. Resend if it may have gone astray; withdraw if you typed the wrong address.
Shown on the public record beside every report filed under this organization.
What appears when this is on
ReportLog
Who can do what here, and a record of who granted it. Nothing on this page can reach a report.
An Access Manager can appoint and remove moderators, create organizations, and appoint the people who run them — and nothing else. They cannot moderate, cannot reach this page's other panels, and cannot appoint another Access Manager. That last one is deliberate: if they could, the role would spread on its own and the ceiling would be gone. Only an admin creates one.
This is also how a moderator is appointed: their address, the Moderator role, Apply. Who currently holds what is in Who is doing what below.
You own this deployment. You are the only person who can appoint or remove an administrator.
Created here, then they run themselves. Verification is a judgement made by whoever creates one — there is no written standard yet, and that is a known gap rather than an oversight.
Everyone holding a role or a membership. There is deliberately no automatic flagging on how much anyone files — high volume is the entire point of a coordinator, and flagging it would fight the design. Oversight is somebody reading this instead.
Every role given and taken away, including an admin's own. Append-only, like the archive.
ReportLog
Working notes for the people running this archive. Nothing here is confidential and nothing here reaches a report.
If you are new, read this page and the one next to it. The rest you can come back to when you need it.
ReportLog is what this archive is called. It is the name to use in anything a member of the public reads.
ReportLog is the software underneath it. It is open source and other people run their own archives on it. Use this name only when you are talking about the software itself — a bug, a release, the source code.
Whatever anybody publishes elsewhere from what this archive releases is their own publication, with its own name. It is not this archive and should never be described as if it were.
Published reports are public. Who filed them is not, ever — it is encrypted and only a moderator can open it, with a reason recorded. Anything you can see because you are on the team is not automatically yours to repeat.
Anything about a specific report, or whether something can be published: a moderator. Anything about the site being broken: file it through the bug form. Anything about what we say publicly: whoever holds the comms desk. If you do not know, ask rather than guess — guessing wrong in public is the expensive kind of mistake here.
This page reads the archive’s own settings, so it is correct for this deployment rather than for somebody else’s.
Plain language, always. Not jargon, not commit-message English, not the language of a press release. Somebody who has just had a bad experience is going to read this. Write for them.
Say what happened, not what it means. The archive records; it does not conclude. "Three people reported the same thing" is ours to say. "There was a co-ordinated effort" is not.
Never call an unreviewed report a fact, in public or in a draft. A report that a moderator has not confirmed is a report, and that is the word for it.
Two colours on this site carry meaning and are not decoration:
Serious crimson is serious, or an error.
Confirmed teal means a moderator confirmed this.
They are the same two colours in every palette the software offers, and the test suite checks them by hue. If you put teal on a graphic because it looked nice, you have told a reader that something was confirmed. Use the accent colour above for anything decorative.
We do not comment on a report that has not been reviewed. Not to confirm it exists, not to characterise it. The line is: "Reports are published once a moderator has reviewed them. I can't discuss anything before that." That is not evasion; a report is somebody’s account and it has not been checked yet.
What is already published, and nothing else. Not who filed it, not what was in a withdrawn version, not what is in the queue. If a published report is being discussed, link to it rather than paraphrasing — the published text is the thing that was checked.
Take the question, say when you will come back, and come back. Nobody is required to answer on the spot, and an answer given on the spot is the one that gets quoted. Anything about numbers should come from the public figures rather than from memory.
That the record cannot be quietly altered, and that anybody can check that for themselves. That is a strong claim and it is true. It is a different claim from "these reports are true", which we cannot make and should never imply. The About page states both limits plainly; borrow its wording rather than inventing a stronger one.
A group whose people file through their own coordinators rather than individually. The organization gets a name on the record and a manager who runs its own membership.
An admin or an Access Manager creates it and appoints its manager. From there it runs itself: the manager invites coordinators, and coordinators file on behalf of people who reported to them.
Verification is a judgement, not a standard. Whoever creates an organization is deciding it is real. There is no written test for that yet, and that is a known gap rather than something being hidden.
An organization can choose to be listed publicly. Being listed shows its name, when it joined, and how many members it has — that last one is an aggregate about them that did not exist before, which is why the opt-in says so rather than just saying "list us".
Listing is not verification and the page says so. Do not describe the directory as a vetted list, because it is not one.
Mostly pointers into the repository. The documents there move with the code; a copy here would not.
ReportLog is AGPL-3.0-or-later at
github.com/munsdev/reportlog.
README.md is the long-form reference for every subsystem
and CONTRIBUTING.md is what to read before changing
anything.
These are in CLAUDE.md and CONTRIBUTING.md,
and breaking any of them breaks the archive rather than a feature:
A field enters the hashed object only when it applies. An absent field and a null one serialize differently, so making an optional field unconditional changes the fingerprint of every report ever filed. It looks like untidy code. It is not.
Reports are append-only. Never UPDATE, never DELETE. A database trigger refuses both, and TRUNCATE separately. A correction is a new row.
The write side and the read side must produce byte-identical objects. A verifier that agrees with the writer by accident is not a verifier.
Migrations are additive. Nothing after the first one changes how an existing report hashes.
Nothing is public until a moderator approves it. There is no auto-publish path and there must not be one.
The transparency log is never rewritten, not even to correct it. If something invalidates published proofs, that fact is published beside them.
The role ceiling. An Access Manager can appoint Moderators and cannot appoint Access Managers.
The gate is frontend as well as backend. Every pane is in the
DOM from the first byte, so while the site is locked
popstate must never route.
Node, PostgreSQL, one Linux server. npm run doctor says
what a machine is missing and installs nothing.
npm run configure writes the half of the configuration a
developer knows; the rest is the setup wizard, in the browser.
contrib/ carries the nginx and systemd templates.
Three suites, all green before anything merges: npm test,
npm run test:db, and the browser suite.
You will be asked how this works. This is enough to answer honestly without pretending to make the decision.
Every report arrives pending. A moderator reads it and marks it valid, invalid, or unknown, and every decision requires a reason. Only valid, non-withdrawn reports appear publicly. Nothing skips this.
It means a moderator judged the report credible on what was in front of them. It does not mean anybody went and checked independently. That distinction matters and is worth making when somebody asks.
Nothing is edited and nothing is deleted. A correction is filed as a new version beside the original and both stay visible. A withdrawal hides a report from public view and the withdrawal itself is part of the record. "We took it down" is never the whole truth here; "it was withdrawn, and you can see that it was" is.
What this archive approves and refuses is on the Standards page, if whoever runs it has written it. If it is not there, say that it is not there rather than describing a standard from memory.
Held separately from the report, encrypted, and readable only by a moderator with a reason recorded. The reporter can see that log entry on their own report. Nobody on the team should ever be asking who filed something out of curiosity, and the log is there because that is a rule with teeth rather than an expectation.
A written answer that names its own author is published as written. The software cannot protect somebody from identifying themselves, and the form says so. If you are helping somebody file, this is the thing to mention.
Do not take a report over a private channel and file it yourself as if it came in normally — the record would then say something that is not quite true about where it came from. Point them at the form, or at a coordinator if they are with an organization. If somebody says they are at risk, that is not a moderation question; say so and get it to whoever handles it.
A vulnerability in the software goes to the address in
SECURITY.md in the repository, not into a public issue and
not into a group chat.
What changed and why, in plain language. The full changelog is on the About page for anybody with tester access.
ReportLog
Everything on this page is a setting for this deployment. Who can do what is on the Access page, which an Access Manager can reach and this one is not. Nothing here can reach a report.
Every time a moderator opened a reporter's identity details, or the untouched original of a file someone attached, with the reason they gave. Ordinary review of a report isn't here — that's public information and logging every glance at it would bury the entries that matter.
Reporters can see these entries on their own reports, with the reason but never the moderator's name. Opening this page is itself recorded.
What this deployment is running, and what is available on the branch it follows. Applying an update takes a database backup first, then installs, migrates and restarts — about a minute, during which the site is briefly down.
A shared password gating the entire site, separate from login — for keeping this off the open internet before launch. When off, anyone can reach the site with no password.
Whether the form is open. This is the other end of the site from the publishing switch below, and the two are independent: this deployment can collect reports while publishing nothing, or stop collecting while everything already approved stays readable.
Closing the form hides it from visitors and refuses both ways a new report can be filed — the public form and coordinator batch entry. It deletes nothing, hides nothing already filed, does not stop moderators working through the queue, and does not stop a reporter correcting or withdrawing a report they have already filed.
Whether this deployment publishes an archive at all. This is the site’s own decision and it is separate from the reporter’s: a report is only ever published if its reporter permitted publication and a moderator approved it and this switch is on. Turning it off withholds the board, the public API, the export and the figures. It deletes nothing, hides nothing from a moderator, and changes nothing about any report’s fingerprint.
Distribution
Nothing distributes yet — there is no distribution in this version, so this switch governs nothing today. It is here so that when there is, no deployment is already doing it by default.
Whether a logbook asks for files is one of its questions, not a setting here — add a “Photos, video or documents” question to it under Logbooks. This page is what this deployment can store, and the handle that stops all of it at once.
The freeze is a protective measure. It refuses every new upload across every logbook, whatever their questions say, and it stops somebody part-way through attaching something with no way to tell them why. It hides nothing already filed or published, and deletes nothing. A single logbook can be frozen on its own under Logbooks — reach for that one first.
Which kinds this deployment will store
Which kinds this deployment is willing to take at all — a question about what its storage and its media worker can handle safely, not about what any one logbook asks for. Narrowing this never invalidates a file that was accepted under a wider list, and never hides one already published.
What this deployment will accept. Leave a box empty to use the number underneath it — the one this software ships with, shown in grey in the box. Typing in a box makes that number yours; emptying it again gives it back.
A single logbook can be narrower than this. Set that on the logbook itself, under Logbooks — what a logbook collects decides what a sane limit is, and one number for the whole site serves an election logbook wanting one short clip and a safety log wanting a dozen photographs equally badly.
These are ceilings, not promises. Raising one does not make a file that was already refused acceptable, and lowering one refuses nothing already filed or published. A limit is checked when something is offered.
Six of these were environment variables until migration 038,
which meant they needed shell access to change, were invisible from this
page, and recorded nobody. If this deployment still sets a MAX_*
variable it feeds the shipped number — so the grey figure may not be
the one this software ships with, and the box here beats it either way.
A report whose own words match anything on this list is flagged for somebody more senior to read. That is all a match means — not a severity, not a finding, and nothing about anybody named in the report. The flag records which words matched, so whoever picks it up does not have to work out why.
One per line. Case does not matter, and a line with
spaces in it matches as a phrase — which is the useful part.
police on its own would fire on every report that mentions
an officer standing peacefully outside, so the shipped list has
police removed and police were called instead.
The shipped list has never seen a real report. It is a starting point written from the shape of the words, not from traffic. Expect to cut from it in the first week: a term that fires on half of what arrives makes the flag useless, and the point of this box is that you can cut it without waiting for a release.
Emptying the box completely is a real answer: it means no keyword matching at all, and it is remembered as your choice rather than read as “not set up yet”.
A logbook is a report form: a title and its own questions. Every report is filed through one, and you can run several at once — for different places, periods or subjects. Each is its own chain, so each can be downloaded and checked on its own, and a problem in one never touches another.
The questions are yours to make. Nothing is built in beyond an address to reach the person, their consent, and whether it may be published. If you want to know when something happened, add a date question. If you want an account in their own words, add a long text question.
What this logbook will accept
Leave a box empty to use the site's number, shown in grey. Typing in a box makes it this logbook's own; emptying it again hands it back. These can be changed after launch.
The logbook file is its title and questions, in plain JSON — to keep, edit by hand, or start a new logbook from. The chain is every report filed to it, sealed, to check with scripts/check-chain.js.
Launching opens this logbook to reporters and fixes its questions for good. After that you can still add a new optional question, and you can close the logbook whenever you like — but no question can be reworded, removed, reordered or made compulsory. A question that could be reworded afterwards would leave every answer to it meaning something nobody can check.
A question added after launch has to be optional. The reports already filed never answered it, and marking it compulsory would have the form claim an answer the archive does not hold.
…is answered with any of these. Tick at least one.
Leave this alone and everybody is asked. A question nobody was asked seals no answer, so a report simply carries nothing under it — which is how a logbook can ask a follow-up without putting it to people it does not apply to.
Leave the opening time empty to start as soon as it launches, and the closing time empty to run until you close it yourself.
A list is a form whose answers are counted, not kept as a record: links people send in, quick check-ins, a contact form. Nothing anybody writes on one is ever published — at most, counts are. What people write and their email address are deleted on a timer; links and choices stay.
If what people send has to be permanent and checkable — an account of something that happened — that is a logbook, not a list.
First: does what people send need to be permanent?
Logbooks are on their own tab.
Start from
A new list starts hidden. Nobody can see it until you say so.
Who can see it
Questions
Unlike a logbook, a list's questions can be changed at any time. A question's answers stay filed under it, so removing one and adding it back later starts its count again.
Counts so far
For you, whether or not they are published. Approving entries is on the Moderators page.
Only a list nobody has sent anything to can be deleted. Once it has entries, stop it taking more instead.
What this deployment is recruiting for — the list the volunteer form offers, in the order it offers them. Editing it here changes the form; there is no deploy and no second copy anywhere.
Disable stops a role being offered on the form and leaves the row here, so you can restore it. A disabled role still reads properly in any confirmation already in flight. Delete removes the row outright, and is offered only while nobody has an application open that names it.
Add a role, or edit one above
A new role is added to the bottom of the list and offered straight away. Edit on a role above loads it here; saving then keeps its place in the list and keeps it switched off if it was off.
The words on your own pages are edited on the pages themselves. Press Edit content in the corner of any page and a pencil appears beside every piece you can change; press it again to stop. Only an administrator is offered it. Each piece starts on the wording the software ships with and says so; clearing one puts that wording back.
This changes what the pages say, not what they are: the layout, the contrast and the print rules are not yours to break by accident.
Three separate dials. Colours is every colour on the site. Type and shape is the lettering, the corners and the edges, and it sets no colour at all. Width is how wide the page runs. Any combination of the three works, so you are not picking from a short list of finished looks.
The colours that mean something are the same in every palette — teal is a moderator confirmed this, crimson is serious or an error. A palette repaints the paper and the button, never those.
Confirmed teal and serious crimson keep their meaning in every palette — they are how the site says what it means, not decoration.
Changing either dial moves these frames and nothing else. The site keeps the look it has until you press Apply to the site.
What this deployment calls itself — shown on every page, in the browser tab, on the lock screen and in the emails it sends. The software is called ReportLog either way, and the footer says so.
Report"Log" gives you the two-tone name
below. Single quotes pick a part out more quietly, in grey:
Munich'Log'. You can use both in one name. The quotes
themselves are never shown, and a name with none in it is one colour.
The two legal pages this deployment publishes, in your own words. Both start as a labelled outline of the things many jurisdictions ask for — an outline is not a legal notice and this is not legal advice. Nothing here is checked for you: what these pages have to say depends on where you run this from, and this software cannot know that. Until you save one, the page says plainly that this deployment has not published it, which is better than publishing an outline.
Positions this deployment publishes that are not the imprint or the privacy policy. They are written on the pages they appear on, the same way as the rest of this site’s words.
Shows the “under active development” badge in the corner of every page. It arms itself for 6 hours whenever a new build is deployed and switches itself off when the window closes — these are the manual overrides.
The owner is one level above an administrator, and the only person who can appoint or remove one. There is exactly one, always.
This cannot be undone. Once somebody else accepts, you are an administrator and they are the owner. Only they can appoint or remove an administrator, and only they can hand the seat on again — including back to you. If the address you give is one nobody reads, nothing happens at all; if it is the wrong person’s, this deployment is theirs.
ReportLog
What you would be able to do
What this does not give you
If you do not want this, close the page. Nothing is created for you and nobody is told either way.
ReportLog
Organizations using ReportLog to put what their people saw on the record. This is evidence that real organizations with real people are doing this — not a competition between them.
No organization has joined the directory yet.
ReportLog
ReportLog
01 · Filing a report
This deployment has not written its guide yet. An operator replaces
these sections with their own; the index builds itself from whatever
carries a data-hownav attribute.
02 · What happens next
Nothing a reporter files is published until a moderator approves it. Replace this with what this deployment actually does, and how long it usually takes.
ReportLog
This deployment has not published an imprint yet. What follows is not one, and is not a draft of one — it is a note about what will be on this page, so you can see what is missing rather than guess.
A statement of who is behind this service. Not a contact form: a named person or organisation who is answerable for what is published here, and a way to reach them directly. In Germany and much of the EU it is a legal obligation with prescribed contents, not a courtesy.
ReportLog ships no imprint and will not invent one. A page that looks like a legal notice but names nobody real is worse than an honest gap: it tells a reader they have been given something when they have not, and it is the kind of thing that only gets noticed when somebody needs it. An administrator writes the real one in Settings, and until they do this page says so plainly.
ReportLog
This deployment has not published a privacy policy yet. What follows is not one, and is not a draft of one — it is a note about what will be on this page, so you can see what is missing rather than guess.
These are unusual, and a reader deciding whether to file something deserves them before the policy exists rather than after. ReportLog is built this way on purpose.
A policy describes what one particular deployment does with particular people's data under a particular jurisdiction. A generic one would be wrong in every specific way that matters, and wrong in a document people rely on is worse than absent. An administrator writes the real one in Settings.
ReportLog
This deployment has not published a moderation standard yet. What follows is not one — it is a note about what will be on this page. A moderation standard is the written rule a moderator applies, and that you can hold them to. It answers three questions for three different people: what a moderator should do with the report in front of them, what a person filing a report can expect to happen to it, and — the one most easily forgotten — what a published report has and has not been checked for. What will be here: what gets published and what is held back, and the fact that holding something back is not a finding that it is false. What it means when a report is marked confirmed. What is never published. What a moderator does when they are involved in the incident themselves. How corrections and withdrawals work, given that nothing is deleted. And what happens when two moderators disagree. Publishing this is not optional for a deployment that takes moderator applications: asking somebody to volunteer to judge other people's reports, without being able to tell them what judgement they are being asked to make, is asking them to agree to an unknown. It is also very hard to write honestly after the fact. Write it before opening an intake, not afterwards.
ReportLog
An operator has published it at another address.
We have sent you a link. Click it and your message is passed on — until then nothing has been.