Pouya/adr-sml
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: cut /legal/privacy/ §Who can see it to four plain statements; name SML Company Ltd on the consent; close Q64 moot

Browse Source 
Two rulings from Pouya, 2026-09-02.

(1) The section stays generic — "it over-explains technical mechanics that
belong in the evidence file, not in front of an inquirer." Deleted: the
measurement paragraph, the root-credential sentence, the SSO/federated-login
enumeration, the resource-policy clause, the "company that runs a database"
aside, the deploy-credential sentence and the three-copies summary. All of it
stays true and stays measured in AGENTS.md §7 and the evidence file, which now
maps each shipped sentence to what it rests on.

(2) The consent string names the corporation: "I consent to SML Company Ltd
storing and using the information in this form…". docs/05 §Consent text moves
with it, proven byte-identical. Two new §4 rows carry the attestations the copy
rests on.

(3) The §Who can see it approval closes via the page read-through, which is now
blocker 2 in docs/06's callout rather than a checklist line.

Q64 closes MOOT — the paragraph it was about was deleted, so it gates nothing.
The underlying gap is unchanged: §7 records root as held by Pouya, not held only
by Pouya, and nothing about root custody may be published without asking again.

Two sentences were added back under review: the shared-account disclosure, to
§Where it is stored (a storage disclosure, never named in the ruling — without
it no page said the intake sits in a shared account), and one naming SML Company
Ltd in the policy, because a consent naming a company the linked policy never
mentions is an accountability gap.

adversarial-reviewer, two rounds, 14 findings, all resolved, none declined;
nine of round 2's ten were defects in round 1's own repairs. claims-auditor
correctly deferred to cutover per D20.

Gates, exit status read: check 0 · build 0 (23 pages) · check:claims 0
(12 patterns, 33 approved strings) · check:intake 0 · og:proof 0 · lint 0 ·
lighthouse 0, worst of 23 99/100/100/100. Tripwire proven both ways — exit 0 on
the revised page, exit 1 with 5 matches on the bd282aa bytes. Regex untouched.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Md3GndFqWPzK78xAoebsg5
This commit is contained in:
Pouya Lajevardi
2026-09-02 12:03:47 -04:00
co-authored by Claude Opus 5
parent 99889a3491
commit 4735989f0b
7 changed files with 602 additions and 259 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/reference/intake-table-access-verification.md
+104 -64
View File
@@ -41,38 +41,63 @@ exact count. **No numeric human headcount may ship.** The identity counts in thi
file are unaffected and stay exactly as measured — this is a correction to what
may be *concluded* from them, not to any of them.
⚠️ **AND RULED A THIRD TIME, LATER THE SAME DAY: THE PAGE STATES WHO, AND THIS
FILE HOLDS THE METHOD.** Pouya, 2026-09-02: *"the page stays generic. It
over-explains technical mechanics that belong in the evidence file, not in front
of an inquirer."* §Who can see it is now **four short statements**. **Deleted from
the page:** the measurement paragraph, the root-credential sentence, the single-sign-on and federated-login enumeration, the resource-policy clause, the *"company that runs a database"* aside, the deploy-credential sentence and the three-copies summary. ⚠️ **THE SHARED-ACCOUNT CLAUSE WAS CUT WITH THEM AND THEN RESTORED — to §Where it is stored, where it belongs.** It is a storage disclosure rather than mechanics, the ruling did not name it, and without it no page told a reader their intake sits in an account that also runs unrelated systems (`adversarial-reviewer`, round 1). **These lists must stay identical — there were four of them and they named four different sets.** None of that was retracted and none of it is lost — it
is all still below, unchanged, and **that is now this file's job rather than a
supporting role.** ⚠️ **THE PAGE NO LONGER CITES THIS FILE'S CONTENT, SO THE
COMPARISON BELOW IS THE ONLY THING TYING THE TWO TOGETHER. Keep it in sync, and
do not restore a deleted sentence to the page on the strength of finding it
here** — the section comment in `src/pages/legal/privacy.astro` carries the same
bar.
**The shipped sentences as at 2026-09-02**, so this file can be compared against
the live page rather than against a struck one:
the live page rather than against a struck one. All four, in order, complete:
> The account's administrators can — me, and the small number of people who
> administer it with me. The table sits in an Amazon Web Services account that
> also runs systems unrelated to this practice, and administrative access to that
> account carries the ability to read the table. That is who can read the stored
> record; who reads the notification email is a separate question, answered in the
> last paragraph of this section.
> The record in the table: me, and the small number of people who administer the
> account it sits in with me.
> The access itself is measured rather than assumed: every user and every role in
> the account was simulated against this table, and every identity that comes back
> able to read it is reachable only by those administrators. The account has no
> single sign-on and no federated login configured, and the table carries no
> policy of its own granting access to anyone. The account's root credential — the
> one path no policy constrains — has no programmatic key, and I hold it.
> The system that receives what you send **can only add a record — it cannot read
> back what is stored.**
> The function that receives the form **can only add a record — it cannot read
> the table back.** And the credential that publishes this website has **no
> access to the table at all**, for reading or for writing.
> The notification goes to the practice's mailbox, which is read by me and by
> administrative staff and is hosted on Google Workspace — so Google holds a copy
> of whatever you send me.
**The wording was approved by Pouya on 2026-09-02 with two trims** (§9 Q63(a)) —
the editorial closing sentence struck, and the mailbox clause rewritten because
`info@smlcompany.ca` is **a delegated mailbox read by Pouya and administrative
staff**, not a personal one (Q63(b); the fact is in `AGENTS.md` §7). **`33` was
deliberately not published**: a role total moves when AWS creates a service-linked
role by itself, and *"every user and every role in the account"* carries the
exhaustiveness without putting a second self-staling number on a legal page.
> The confirmation that went to you sits with whoever runs your email. That copy
> is in your hands rather than mine.
⚠️ **AND THE ENUMERATION BELOW WAS NOT ENOUGH TO SUPPORT THE SECOND OF THOSE
SENTENCES. See the addendum at the foot of this file**, which is what the page
actually rests on. Read it before citing the five-row table.
**What each rests on, because that mapping is the reason this file exists.**
Sentence 1: the enumeration below, plus Pouya's *"a handful"* attestation for the
human quantifier — **the measurement gives administrators, the attestation gives
the number, and neither gives the other.** Sentence 2: `adr-intake-lambda-role`
holds `PutItem` only, implicitDeny on all six read and modify actions.
Sentence 3: **an attestation, not a measurement** — `AGENTS.md` §7's
`info@smlcompany.ca` row; nothing in this repository or in AWS can check it.
Sentence 4: the handler's second `SendEmailCommand`.
**Three things the page deliberately does NOT say, and each was deleted by
ruling rather than being unsupported.** The **root credential** (§7 records it as
held by Pouya with no access key and MFA on — ⚠️ *held*, not *held only*, which
is why publishing it needed a question and why §9 Q64 is closed as **moot** and
not as answered). The **single-sign-on and resource-policy findings**. And the
**`33`** — deliberately withheld even while the paragraph stood, because a role
total moves when AWS creates a service-linked role by itself.
**The wording approval Pouya reserved is discharged by the read-through** — his
ruling, 2026-09-02: *"do not hold anything open waiting on a separate wording
approval; the read-through is the approval."* Q63(a) had approved a version, and
the version changed twice after it.
⚠️ **AND THE ENUMERATION BELOW WAS NOT ENOUGH TO SUPPORT THE COMPLETENESS CLAIM
— *"every user and every role in the account was simulated against this table"*,
which §7 still asserts and the page no longer carries. See the addendum at the
foot of this file**, which is what that claim actually rests on. Read it before
citing the five-row table. *(This pointer said "the second of those sentences"
until 2026-09-02: it indexed the quote block by POSITION, and the block changed
length under it. Name the claim, not its ordinal.)*
---
@@ -211,10 +236,19 @@ a silently-skipped iteration is visible as a missing row, and suppresses nothing
## ⚠️ ADDENDUM 2026-09-02 — THE ENUMERATION ABOVE WAS INCOMPLETE IN THREE WAYS, AND ITS CONCLUSION SURVIVES ANYWAY
**Why this addendum exists.** `/legal/privacy/` publishes a completeness claim
about who can read this table — the second of the three sentences quoted at the
top of this file, under **The shipped sentences**. Written as it stood, this file
did not support it.
**Why this addendum exists.** `/legal/privacy/` published a completeness claim
about who can read this table — *"every user and every role in the account was
simulated against this table"* — and, written as it stood, this file did not
support it. ⚠️ **THAT SENTENCE IS NO LONGER ON THE PAGE**: Pouya ruled later the
same day that the section states who and not how, and the measurement paragraph
was deleted (see **The shipped sentences** at the top of this file, which is now
four statements and does not include it). **This addendum is not thereby
obsolete — it is now load-bearing in a different place.** `AGENTS.md` §7's
`Intake table — who can read it` row still asserts the completeness, `docs/06`
and §12 **R21** still instruct an operator to re-run it before cutover, and the
page's first sentence still rests on its conclusion even though it no longer
recites the method. **A claim moved off a public page into a register is still a
claim.**
*(This paragraph quoted a different sentence until 2026-09-02 — round 1's
**pre-fix** wording, *"every account and role in this infrastructure…"*, which
@@ -234,7 +268,7 @@ construction even when it happens to be true.
2. **No role was ever simulated against the table.** Access was inferred from
policy *names* (`AdministratorAccess`) rather than measured as a decision.
3. **The five users were simulated for reads only** — `GetItem`, `Query`, `Scan`.
So the page's *"the credential that publishes this website has no access to the
So the page's *(then-shipped; deleted by the mechanics ruling of 2026-09-02 and now §7's alone)* *"the credential that publishes this website has no access to the
table at all"* covered three read actions and said "at all".
**What the measurement found, and it changes the role count.** Simulating all 26
@@ -351,44 +385,50 @@ always read the table. Two facts bound it: `get-account-summary` reports
and `AccountMFAEnabled: 1`. Root access therefore requires the root password and
its MFA device.
⚠️ **THIS PASSAGE SAID *"The page does not mention root and should not"*, AND
THAT JUDGEMENT IS SUPERSEDED — §9 Q63(c), 2026-09-02.** It was reasoned from its
own last clause: *"Who holds the root credentials is not established in this
repository."* **Pouya established it on 2026-09-02: he holds it**
`[verified 2026-09-02 — Pouya]`. With the holder known, mentioning root
**strengthens** the paragraph rather than opening a hole in it — it closes the
one path a careful reader would ask about after being told every user and every
role was simulated. The page now states that the root credential has no
programmatic key and that he holds it; it does not state a headcount for it, and
`AGENTS.md` §7 carries the fact with §12 R21's trigger on it. ⚠️ **AND THE
ATTESTATION IS *held by Pouya*, NOT *held ONLY by Pouya* — §9 Q64 is open on
exactly that gap.** Nothing here excludes a second holder: root cannot be
simulated, and `get-account-summary` reports only that there is no access key and
that MFA is on. The shipped possessive sits one paragraph below *"the small
number of people who administer it with me"*, where a reader takes it as sole
custody. **This is the identity/human error of Q63 pointing the other way** — one
line from Pouya either arms it or strikes the possessive. The rest of the
original reasoning holds and is why the sentence is still scoped the way it is:
an account owner's own credential is inherent to every cloud account and is not a
third party who has been granted access, which is why the shipped sentence is
scoped to *"every user and every role"* and to who has been *granted* access
rather than to a bare "nobody else can".
⚠️ **THE PAGE SAYS NOTHING ABOUT ROOT, AND THIS PASSAGE HAS NOW BEEN THE REASON
FOR THAT TWICE ON OPPOSITE GROUNDS.** It first read *"The page does not mention
root and should not"*, reasoned from its own last clause — *"who holds the root
credentials is not established in this repository."* **Pouya then established it
(§9 Q63(c), 2026-09-02): he holds it** `[verified 2026-09-02 — Pouya]`, the page
published *"has no programmatic key, and I hold it"*, and the gap that opened
immediately was that *held by* is not *held only by* — a reader takes the
possessive as sole custody, which nothing measured or attested supports (§9
**Q64**). **His second ruling that day deleted the sentence** along with the rest
of the mechanics, so **Q64 is closed as MOOT rather than answered and the
underlying fact is exactly as unestablished as it was.**
**Two page sentences are now supported that were not before.**
**The consequence to carry, because it is not "nothing happened":** root custody
is now recorded in `AGENTS.md` §7 and nowhere public. ⚠️ **Nothing about it may
be published without asking him again**, and the question to ask is not *who
holds root* — that is answered — but *whether anyone else does*. The original
reasoning still holds and is why the page's first sentence is scoped as it is: an
account owner's own credential is inherent to every cloud account and is not a
third party who has been *granted* access, which is why the measured claim was
always scoped to *"every user and every role"* rather than to a bare "nobody else
can".
- *"The function that receives the form can only add a record and cannot read the
table back"* — `adr-intake-lambda-role` returns `allowed` for `PutItem` and
`implicitDeny` for `GetItem`, `Query`, `Scan`, `BatchGetItem`, `UpdateItem` and
`DeleteItem`. Previously this rested on reading the policy document; it is now
the simulator's decision.
- *"the credential that publishes this website has no access to the table at
all"* — `adr-sml-deploy` is `implicitDeny` on all **seven**, so "at all" now
covers writes and deletes as well as reads.
**Two claims are supported that were not before. One of them still ships; the
other was deleted from the page by ruling on 2026-09-02 and is kept here because
it remains true and remains §7's.**
- **SHIPS** — *"The system that receives what you send can only add a record — it
cannot read back what is stored"* — `adr-intake-lambda-role` returns `allowed`
for `PutItem` and `implicitDeny` for `GetItem`, `Query`, `Scan`,
`BatchGetItem`, `UpdateItem` and `DeleteItem`. Previously this rested on
reading the policy document; it is now the simulator's decision.
- **NO LONGER ON THE PAGE** — *"the credential that publishes this website has no
access to the table at all"* — `adr-sml-deploy` is `implicitDeny` on all
**seven**, so "at all" covers writes and deletes as well as reads. It went with
the mechanics cut, not because anything about it changed.
**And it corroborates §10 from the IAM surface.** Of the 26 non-service-linked
roles, **9 belong to CDK bootstrap** and **14 to four unrelated production
systems** in the same account — which is what `/legal/privacy/` now tells a
reader in as many words. *(Their role names were listed here until 2026-09-02 and
systems** in the same account. *(`/legal/privacy/` tells a reader this in as many words —
*"The table sits in an Amazon Web Services account that also runs systems
unrelated to this practice"* — in **§Where it is stored**, which is where the
sentence now lives: the mechanics cut removed it and it was restored there, as a
storage disclosure rather than a method. §10 is unaffected either way; it never
depended on the page saying so.)* *(Their role names were listed here until 2026-09-02 and
are not any more: this is a committed file, they are another project's IAM
surface, and the count carries the whole of the argument. `adversarial-reviewer`,
round 2.)*