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

feat: rule Q63 in three limbs; take the human headcount off /legal/privacy/; close R10; ratify /med-arb/

Browse Source 
Pouya's rulings, 2026-09-02.

Q63(a) — wording approved with two trims: the editorial closing sentence is
struck, and the mailbox clause is rewritten per (b).

Q63(b) — info@smlcompany.ca is a delegated mailbox read by Pouya and by
administrative staff. The page said "anyone who can reach that mailbox"; it now
says who. The answer reached four sentences, not the one the ruling named, in
three sections: "my mailbox" had been written as a personal one throughout.

Q63(c) — the account root credential is held by Pouya, has no programmatic key
and carries MFA. The page now states the first two.

And the answer to (c) took the human headcount off the page. His attestation:
"two people is an exaggeration... a handful is accurate — the simulation counts
identities, not humans, and the two are not the same claim." The enumeration was
exhaustive and the inference off it was not: two IAM identities is a LOWER BOUND
on people and was published as an exact count. The page now attributes read
access to "the account's administrators — me, and the small number of people who
administer it with me", and the false inference is corrected at its source in
docs/reference/intake-table-access-verification.md as well as on the page.

R10 — CLOSED on a fresh one-line confirmation, not on the 2026-08-28 stamp.
ADRIC, ADRIO, the three OBA sections and the CTF all current. Re-stamped on all
four stamp-bearing sites; the row stays live, because its trigger is an event.

/med-arb/ — ratified as shipped, no credential line restored. His note for the
record: med-arb is a service he provides, not a designation.

The tripwire is unchanged and proven both ways: exit 0 on the revised page,
exit 1 with 5 matches on the pre-correction bytes rebuilt from bd282aa.

A sentence added to back the correction had no command behind it. "The table
carries no policy of its own granting access to anyone" was published with
nothing in the repo establishing it — a DynamoDB resource policy is invisible to
describe-table, and every simulation on file asks what a principal may do.
Measured rather than deleted: get-resource-policy returns PolicyNotFoundException,
and describe-organization returns AWSOrganizationsNotInUseException, which is
what makes the Identity Center zero conclusive rather than merely local. Both
recorded as commands 7 and 8; R21 gains claim (v) and two falsifiers.

Q64 OPENED, with a TODO(pouya) and an unticked cutover item: "I hold it" is true
whether or not a second person holds it, and reads as sole custody one paragraph
below "the small number of people who administer it with me". The request to
strike the possessive now is declined with a reason — he dictated the clause —
and the page cannot ship while the TODO stands.

Two review rounds, 22 findings, 21 resolved, 1 declined. Nine of round 2's twelve
were defects in round 1's own repairs. Stopped at two per D19.

Gates, exit status read: check 0 · build 0 (23 pages) · check:claims 0 ·
og:proof 0 · check:intake 0 · lint 0 · router.test 0 (30/30) · lighthouse 0,
worst of 23 99/100/100/100, /legal/privacy/ 100/100/100.

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 11:00:15 -04:00
co-authored by Claude Opus 5
parent 6aaf089b05
commit 99889a3491
9 changed files with 641 additions and 185 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/reference/intake-table-access-verification.md
+123 -28
View File
@@ -26,26 +26,49 @@ trusting this file; it is dated for that reason.
2026-09-01, applied 2026-09-02). Option 2 below is the one taken; option 1 was
declined. `lars`'s membership of `admins` is **unchanged**.
**The shipped sentences**, so this file can be compared against the live page
rather than against a struck one:
⚠️ **AND THEN RULED AGAIN THE SAME DAY — §9 Q63, and the second ruling is the
one this file most needs to carry, because THIS FILE SUPPLIED THE ERROR.** The
first shipped sentence was *"Two people can"*, and it was read straight off the
enumeration below. **Pouya's attestation, 2026-09-02:** *"two people is an
exaggeration… a handful is accurate — the simulation counts identities, not
humans, and the two are not the same claim."*
> Two people can. The table sits in an Amazon Web Services account that also
> runs systems unrelated to this practice, and that account has two
> administrators — me, and one other person who administers it with me.
> Administrative access to the account carries the ability to read the table, so
> both of us can read what you send.
**The enumeration is exhaustive and the inference off it was not.** Every read
path terminates at `user/pouya` or `user/lars`; how many **people** can reach
those two credentials is not something `simulate-principal-policy` can see, so
the identity count is a **lower bound on people** and the page published it as an
exact count. **No numeric human headcount may ship.** The identity counts in this
file are unaffected and stay exactly as measured — this is a correction to what
may be *concluded* from them, not to any of them.
> No one outside those two people has been granted access to the table, and that
> is measured rather than assumed: every user and every role in the account was
> simulated against this table, and the only ones that come back able to read it
> lead to those same two people.
**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 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 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 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.
**Wording is subject to Pouya's read-through approval** — §9 **Q63**, with a
`TODO(pouya)` beside the copy. The measurement is settled; the phrasing is not.
**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.
⚠️ **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
@@ -289,8 +312,36 @@ many roles exist but which *people* they lead back to.
`[verified 2026-09-02]`. So "every user and every role" is not leaving out a
federated principal, because there is none to leave out.
Every read path therefore terminates at `pouya` or `lars`. **The count of people
is two, and it is now the result of an enumeration rather than of a policy name.**
- ⚠️ **AND THE `sso-admin` ZERO NEEDED A SECOND COMMAND TO MEAN ANYTHING, added
2026-09-02 (round 2).** `list-instances` answers about the account it is called
in, so a **member of an AWS Organization returns 0 while Identity Center runs in
the management account** — the zero would have been true and the conclusion
false. `aws organizations describe-organization` returns
**`AWSOrganizationsNotInUseException`: "Your account is not a member of an
organization"** `[verified 2026-09-02]`, so there is no management account above
this one and the zero is conclusive. Command 8.
- **The table carries NO RESOURCE-BASED POLICY OF ITS OWN**, and this is now a
command rather than an assertion. `aws dynamodb get-resource-policy` returns
**`PolicyNotFoundException`** `[verified 2026-09-02]` — exit **254**, the error
on stderr being the result. ⚠️ **A DynamoDB resource policy is invisible to
`describe-table`**, so no earlier command in this file could have seen one, and
`/legal/privacy/` publishes the claim (*"the table carries no policy of its own
granting access to anyone"*). It is the identity-policy enumeration's blind
spot: every simulation here asks what a **principal** may do, and a resource
policy grants from the other side. Found unbacked by `adversarial-reviewer`
round 2, on §10's own precedent — the client-backup bucket, where
`get-bucket-policy` returning `NoSuchBucketPolicy` was recorded because *"a
policy read alone could not have established the second half."* Command 7.
Every read path therefore terminates at `pouya` or `lars`. ⚠️ **AND THAT IS
WHERE THIS FILE WENT WRONG, SO THE CORRECTION SITS AT THE SENTENCE THAT CAUSED
IT.** This read *"The count of people is two, and it is now the result of an
enumeration rather than of a policy name"* until 2026-09-02, and `/legal/privacy/`
published that count. **It is a count of IDENTITIES.** Two credentials is a lower
bound on the number of people who can use them, and Pouya's attestation is that
*"a handful"* is the true figure (§9 Q63). The enumeration stands exactly as
measured; **an enumeration of principals is not a census.**
**The account root user, recorded because an enumeration that quietly omits it is
not an enumeration.** Root is not an IAM user and does not appear in
@@ -298,13 +349,30 @@ not an enumeration.** Root is not an IAM user and does not appear in
always read the table. Two facts bound it: `get-account-summary` reports
`AccountAccessKeysPresent: 0`, so **there is no programmatic root credential**,
and `AccountMFAEnabled: 1`. Root access therefore requires the root password and
its MFA device. **The page does not mention root and should not**: 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". Who holds the root credentials is not
established in this repository; it is not a page-blocking fact, and it is noted
here rather than guessed at.
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".
**Two page sentences are now supported that were not before.**
@@ -347,8 +415,14 @@ a variable, which is the whole point above.
```bash
# 1. Inline policies — the command the original block never ran.
# ⚠️ THE `grep -v` IS THE ORIGINAL DEFECT AND IS KEPT ONLY TO SHOW IT. It
# excluded the 7 service-linked roles from a claim written as "every role", and a
# service-linked role for a backup or migration service CAN read table contents.
# For a full run, DELETE the grep -v — all 33 must be screened, which is what the
# 2026-09-02 addendum measured and what the page's "every user and every role"
# now rests on.
aws iam list-roles --query 'Roles[].RoleName' --output text \
| tr '\t' '\n' | grep -v '^AWSServiceRole' \
| tr '\t' '\n' \
| while IFS= read -r R; do
aws iam list-role-policies --role-name "$R" --query 'PolicyNames' --output text
done
@@ -391,10 +465,31 @@ aws iam list-open-id-connect-providers --query 'length(OpenIDConnectProviderList
aws sso-admin list-instances --query 'length(Instances)'
aws iam get-account-summary \
--query 'SummaryMap.{AccessKeysPresentRoot:AccountAccessKeysPresent,MFA:AccountMFAEnabled}'
# 7. The table's OWN policy. ⚠️ NOT VISIBLE IN describe-table — a DynamoDB
# resource policy needs its own call, and the page publishes a claim about it.
# A "no policy" answer arrives as a NON-ZERO EXIT with PolicyNotFoundException
# on stderr, so do not suppress stderr and do not read exit 0 as the result.
aws dynamodb get-resource-policy \
--resource-arn 'arn:aws:dynamodb:ca-central-1:327082975128:table/adr-intake-submissions'
# 8. Is the account in an AWS Organization? ⚠️ THIS IS WHAT MAKES COMMAND 6's
# sso-admin ZERO CONCLUSIVE. `list-instances` answers about THIS account, so a
# member account returns 0 while Identity Center runs in the management
# account. Not-in-an-org means there is no such management account.
aws organizations describe-organization
```
**Five user rows and twenty-six role rows, or the run did not happen.** And for
every simulation: **seven decisions per role call, six per CDK-path call, two
per-resource decisions per assume call** — the counts are the assertion, because
a call that silently received one bogus action name answers `implicitDeny` and
reads exactly like a clean row.
**Five user rows and THIRTY-THREE role rows, or the run did not happen.** ⚠️
**This said "twenty-six" until 2026-09-02, which made an INCOMPLETE sweep pass
its own acceptance test** — the number matched command 1's `grep -v
'^AWSServiceRole'`, so an operator following §12 R21's instruction to re-run this
file would have reproduced the exclusion and got the pass line for it. The page's
*"every user and every role"* rests on 33 of 33. `adversarial-reviewer`, round 2.
And for every simulation: **seven decisions per role call, six per CDK-path call,
two per-resource decisions per assume call** — the counts are the assertion,
because a call that silently received one bogus action name answers
`implicitDeny` and reads exactly like a clean row. **Commands 7 and 8 are read by
their ERROR, not their output**: `PolicyNotFoundException` and
`AWSOrganizationsNotInUseException` are each the clean result, arriving on stderr
with a non-zero exit.