For a representative’s office · checked 2026-10-01
What this site offers your office, and what it will never do to you
interns.city publishes what residents report about places, and who is obliged to answer for each kind of problem. It does not publish a judgement about you. There is no score on this site, no ranking, and no page that orders members by how they are doing — the versions of this site that had those were deleted rather than improved.
This page is the offer, stated so that you can hold us to it. Each item below says what the code does today, and the ones that do not exist say so in those words. Every claim on this page is a claim about our own software, so the evidence under each one is the file you would open to catch us out.
What your office gets
Five things, in the order an office tends to care about them. The first one does not exist yet, and it is first precisely because it is the thing we would most like to be able to promise you. Two of the others are built and automatic, and have nevertheless never been observed to reach anybody — where that is so, the record is printed under the item rather than left for you to discover.
A standing alert feed for your ward or constituency
Does not exist yetThere is no subscription of any kind on this site. No table holds a list of addresses to notify, nothing assembles a daily or weekly digest, and the only two scheduled jobs that run are a weekly Twitter scan and a nightly snapshot of the public mirror. An office cannot sign up for anything here today, and no form on this page pretends otherwise.
What is missing: a subscriptions table, a digest assembler, and a scheduled job to send it. None of the three exists.
Where to check this
- vercel.json — Two cron entries exist: /api/cron/scan-twitter weekly and /api/cron/snapshot-mirror nightly. Neither notifies anyone of anything. Read 2026-10-01.
- supabase/ — No migration in the directory creates a subscription, alert, digest or watchlist table, applied or unapplied. Read 2026-10-01.
Every new report in your jurisdiction, by email, if you are the executing agency
Working nowWhen a signed-in resident files a report, the site resolves the department that executes that category in that city, and the District Magistrate or Collector for that district, and emails both at the published institutional address held for them. The email carries the title, the category, the urgency, the address, the description where the resident wrote one, and two links — the public report page and the point on the map. The photographs are on the report page; they are not attached to the email. At most three such emails are ever sent per report, and nobody is emailed twice about the same one. Reports filed without an account go to a moderation queue instead and notify nobody.
What the record actually shows
No such email has ever been recorded. The table that logs every authority email this site sends holds no rows at all, and all 69 reports filed so far were filed by signed-in residents — which is the exact condition that is meant to trigger one. So the code path is wired and has never once been observed to complete.
An empty table has two possible causes and this count cannot separate them: either no department address ever resolved for the places reported so far, or the send failed each time. The row is written only after the send succeeds, and a failed send is swallowed into a log line, so the absence of a row is not evidence about which.
Read from public.authority_emails, counted against public.issues, read with the public key on this date, on 2026-10-01.
What you do: Nothing to do, and nothing to expect yet. It is supposed to happen automatically, to the address published for the office — but see the record above before you rely on it. If the address we hold is wrong, that is a correction and the route for it is below.
Where to check this
- src/app/api/auto-notify/route.ts — Fires on every signed-in submission; resolves the category department and the district officer; sends through SES with a per-report cap of three recipients and a duplicate guard read off authority_emails. Read 2026-10-01.
- src/lib/authorities.ts — The addresses it sends to are departmental and district inboxes held in this file. No personal address appears in it. Read 2026-10-01.
- src/app/api/anon-report/route.ts — Reports filed without an account land in a review queue and trigger no email. Read 2026-10-01.
Your reply published word for word, under your own name, beside the report
Working nowEvery notification email carries a Reply-To address unique to that one report. A reply to it is published on the report page as the office's own answer, carrying the name and address it was sent from and marked as an authority reply. The text is published as written — the only thing removed is the quoted copy of our own email underneath it. No account, no password and no sign-up: replying to the email is the whole mechanism. We cannot edit what you send; moderation on this site can delete a comment but has no power to rewrite one.
What the record actually shows
No reply has ever arrived this way. One comment on the whole site is marked as an authority reply, and it carries neither a sender address nor a sender name — the two fields this route fills in on every message it publishes — so it did not come through this path. Nothing has.
This follows from the offer above it: no notification email has been recorded as sent, so no reply address has gone out for anyone to reply to. It is not evidence that the inbound route itself is broken, and it is not evidence that it works. Whether the mail service is configured to deliver to it at all is a setting outside this repository, and nothing in here can read it.
Read from public.comments where is_official is true, read with the public key on this date, on 2026-10-01.
What you do: Reply to the notification email as you would to any other correspondent, if one reaches you. Your reply appears on the report page.
Where to check this
- src/app/api/auto-notify/route.ts — Sets ReplyToAddresses to a per-report address at the reply subdomain. Read 2026-10-01.
- src/app/api/inbound-email/route.ts — Verifies the inbound message signature, extracts the report id from the address, strips the quoted thread and nothing else, and publishes the reply against that report with the sender name and address recorded. Read 2026-10-01.
- supabase/comments_is_official_migration.sql — The authority-reply marking is derived on the server and cannot be set by a browser, and the sender name and address are server-owned in both directions — a later edit cannot erase or alter them. Read 2026-10-01.
A route to dispute any single field we hold about your seat
Working nowThere is a page for exactly this, and it takes one field at a time: you pick the field from a list of everything we publish, name the document that settles it, and say which of two things you are doing — asserting the field is factually wrong, or accepting that it is accurate and objecting to it anyway. The second is a right of reply: the record does not change and your objection is published beside it in your words. You may write as the office the page is about, and that capacity is recorded as stated rather than as verified, because that route asks nobody to prove who they are. Every record page also still carries a correction link prefilled with the record URL and the row id. A field changes against a better document and against nothing else — not on our assertion and not on an office's, because a record that moves when somebody insists is not a record.
What you do: Use the corrections page, one field and one document at a time, or the correction link on the seat's own record page. Read the already-known defects listed there first — sixteen of them, and the thing you were about to report may be one.
Dispute a field, or reply to one you accept is accurate
Where to check this
- /representatives/corrections — The dispute route. Lists the correctable fields grouped by page, both tracks, the capacity you can write in, and the defects we already know about. Read 2026-10-01.
- src/app/api/correction/route.ts — Where a submission goes. It tries the database, falls back to emailing the same inbox when the table is absent, and answers with a page naming which of the two happened — or saying plainly that it was not received. It never reports success it did not have. Read 2026-10-01.
- supabase/2026_10_corrections.sql — Written and NOT applied. So a submission today is emailed to a person rather than written to the public log, and the corrections page says so on itself instead of showing an empty table. Read 2026-10-01.
- src/app/representatives/[slug]/page.tsx — Renders a correction mail link prefilled with the record URL and row id, and renders a known-wrong-value notice above the identity block when a stored field is known to be wrong. Read 2026-10-01.
An export of the reports filed in your area
By hand, on requestThere is a public export, and it is not filtered by area. One endpoint publishes a snapshot of up to a thousand recent reports — id, title, category, urgency, status, address, upvote count and date — with no key required, for anyone to re-host. There is no ward, constituency or district filter on it, and no download button anywhere that produces one. Separately, any single report has a printable evidence pack at its own URL. An export cut to one ward or one constituency is something we would run and send you; it is a query someone types, not a feature.
Who does it: the founder runs the query and emails you the file. There is no endpoint that takes an area and returns rows.
What you do: Ask, naming the ward or constituency and the period. The unfiltered snapshot is already public and needs no permission at all.
Where to check this
- /api/mirror — The public snapshot. Site-wide, capped at a thousand recent reports, open to any caller, with no area parameter. Read 2026-10-01.
- src/app/issue/[id]/dossier/page.tsx — A printable evidence pack for a single report, at that report's own URL. Read 2026-10-01.
What this site will never do
These are not intentions. Each one is already true of the code, and where the site used to do the thing, the entry says so — you are entitled to know what was once published about you and what happened to it.
We will not give you a score.
No number on this site stands for how well you are doing your job. There is no responsiveness percentage, no grade and no index against your name.
Why that holds: This site used to score members, on figures it had invented — an attendance default of 50% applied to the 523 rows that had none, and a radar chart on which "we hold no data" and "they did nothing" drew the identical shape. All of it was deleted rather than corrected, and the public snapshot that handed the derived ranking to third parties no longer carries it.
Where to check this
- src/app/representatives/page.tsx — The removal log at the top of the file records each scored view that was deleted and the specific invented number it rested on. Read 2026-10-01.
- src/app/api/mirror/route.ts — States that the accountability view — members ranked by unanswered complaints — is deliberately no longer published, and why. Read 2026-10-01.
We will not rank you against other members.
Nothing here orders members by performance. There is no league table, no "best" and no "worst", and no page where your seat is compared with a neighbouring one on a number.
Why that holds: The ranking view was dropped from the database, not hidden in the interface, and the per-member comparison tool was deleted along with the control that collected members into it. Sorting on the list page is by name only.
Where to check this
- src/app/representatives/page.tsx — The comparison modal and the add-to-comparison control are recorded as removed, and the remaining sort is name ascending or descending. Read 2026-10-01.
We will not publish a bottom list.
There will be no page naming the members who answered least. Not as a chart, not as a table, and not as a sentence in a release.
Why that holds: The data that would produce one is self-reported by residents and, in practice, came from effectively a single real row. A list that thin, published with permissive caching for others to re-host indefinitely, is not something a later correction can catch up with — so the count stays unpublished until it means what its column name says.
Where to check this
- src/app/api/mirror/route.ts — Records that the ranked view is withheld because it derives from self-reported pings and in practice from one row, and that a re-hosted figure cannot be corrected afterwards. Read 2026-10-01.
We will not publish your personal phone number, home address or private email.
Residents are sent to your office's published channels and to the agency that executes the work. They are not handed a way to reach you at home.
Why that holds: The representatives table has email, phone and website columns and they are empty on all 571 rows; the record page prints that we hold none rather than filling the space. For the launch city's 36 wards the corporation publishes an address for every councillor and not one is an office address — 36 at one free mail provider, two at another, none on the corporation's own domain, and ten sharing no part of the name printed beside them. All 36 are withheld, with the reason printed on the page, and residents are routed through the corporation's own channels instead.
Where to check this
- src/lib/wards.ts — Every ward carries an explicit withheld-contact state with the reason, and the file states that nothing in it is a personal phone number or a home address. Read 2026-10-01.
- src/lib/tiers.ts — States that contact routes are institutional only and that no personal number, home address or private email may be added. Read 2026-10-01.
The code a submission has to pass before it appears next to your name
Published here rather than kept internally, so that you can tell when we have failed to apply it. Anger about a decision is not a breach of any of these; every rule below is about something other than anger.
- No insults.
- Abuse aimed at a person rather than at a decision comes down. "This road has been broken for two years and nobody answered" stays up, however angry it is. A slur or a jibe about appearance, caste, family or competence does not.
- No incitement.
- Nothing that calls for harm, that urges people to an address, or that reads as a threat — to you, to your staff, or to anyone else named in a report.
- No discrimination.
- Nothing that attacks a person on religion, caste, region, language, gender, disability or sexuality — including where it is aimed at a resident in a comment rather than at an office.
- No questions about your private life.
- Your family, your health, your finances and your relationships are not in scope on this site. A submission that asks about them is removed whether or not it is polite.
- No requests that ask you to use official discretion.
- A request to move a particular file, to favour one claim over another, to transfer an officer, or to arrange anything for a named individual is not a civic report and is not published as one. The site asks what an office is obliged to do, not what it could be persuaded to do.
And we tell you when we reject something on your behalf
By hand, on requestWhen we reject a submission about you under the code above, we tell you it happened — what it concerned, which rule it failed, and that it was not published.
Who does it: a person writes to you. Nothing on this site sends such a notice automatically, and there is no queue that would chase it if it were forgotten.
Moderation here removes; it does not rewrite. A comment can be deleted and a resident can flag one for review, but there is no mechanism that edits somebody's words and leaves them attributed to them.
Where to check this
- supabase/comment_moderation_migration.sql — Moderators can delete a comment and any signed-in resident can flag one, once. There is no moderator edit path. Read 2026-10-01.
- src/app/api/admin/anon-reports/route.ts — The review queue for reports filed without an account, where a submission can be approved, rejected or marked spam. It notifies nobody when it rejects. Read 2026-10-01.
How a claim is checked, and why a person does it
Three steps. None of them is automated, and that is the design rather than a gap in it.
You write from an address already on record as official for the seat — the one published by the corporation, the assembly, the Lok Sabha or Rajya Sabha directory, or the department.
This is the only part of a claim that can be checked against something we did not get from the claimant. An address you give us is not evidence; an address the institution published is.
Done by a person
One person — the founder — reads the claim, opens the published source, and confirms the address against it by hand.
There is no self-serve flow, no automated domain check and no confirmation link that grants anything on its own. A claim is approved by somebody looking at it or it is not approved.
Done by a person
We write back saying what was approved, in words, and what it does and does not let you do.
So there is a record on your side of what was granted, rather than a state change you have to infer from the site.
Done by a person
Why there is no self-serve version of this
Letting the wrong person speak as a representative is the worst thing this page could cause — worse than a slow reply, and not fixable by a correction afterwards, because the words will already have been read. At the scale this site is actually at, a launch city and a handful of offices, automating the check would save a few minutes a month and would remove the only step that catches an impersonation. So it stays manual, and it stays manual on purpose rather than because nobody has got round to it.
What claiming a seat cannot do
Stated before you write, not afterwards. An office that reads this and still wants the reply route is an office this site can work with.
It cannot change what we hold about your seat.
A correction still needs a source we can check, and it goes through the same route a resident's correction goes through. A claimed office gets a faster reader, not a different standard.
It cannot delete a report.
A report is a resident's account of a place. If it is false or it identifies someone it should not, say so and it is dealt with as that — not as a claim about who owns the record.
It cannot edit a resident's words.
Nothing on this site can. Moderation deletes; there is no path that rewrites a comment and leaves it attributed to the person who wrote it.
It cannot remove a delivered message from the log.
The record that an email reached a named official inbox on a date is the only thing the escalation clock on an issue page runs on. Removing it on request would make every clock on the site unreliable, including the ones that currently show an office answered quickly.
It cannot stop a report being filed about your area.
Residents file reports about places, not about people. Claiming a seat gives you the reply, the dispute route and the export; it gives you nothing over what gets reported.
How to start
There is no form on this page and no account to create. Nothing here records a claim, because there is no claim system to record it in — a form that collected your seat and your official address and dropped them would be worse than this paragraph. So the whole mechanism is an email that a person reads.
Write to us about a seatOpens your mail app with the three things the check needs already listed. It goes to admin@interns.city, which is one inbox read by one person — so expect a reply from a human being, and expect it to take longer than a confirmation link would.
If you would rather not claim anything: you do not have to. The reply route in the offer above needs no claim, no account and no permission from us. Replying to the notification email your office already receives publishes your answer beside the report on its own.