feat: rule Q62 by stating the truth; strike the /med-arb/ gloss; re-stamp R18
Pouya's four rulings of 2026-09-01, applied 2026-09-02.
Q62 — RULED "state the truth", not "remove the access". /legal/privacy/
now says two people can read the intake table, names their role, and adds
the two stronger facts the false sentence had crowded out: the handler
role holds PutItem only, and adr-sml-deploy is implicitDeny on all seven
read and write actions. Wording is subject to Pouya's read-through —
Q63(a), with a TODO(pouya) beside the copy.
The ruling named one sentence; a vocabulary sweep found the falsehood in
three places, and the audit then found two more. Five paragraphs now
answer "who can see it" and change together.
The tripwire stays permanently, per ruling, and grew from two
alternatives to five. Every alternative is one string that reached dist/.
Proven both ways against the pre-correction page rebuilt from bd282aa:
exit 1 with 5 matches at dist/legal/privacy/index.html:54,67,67,68,72;
exit 0 on the corrected page, self-test 12 patterns / 36 approved
strings.
/med-arb/ — the gloss is struck with no replacement, per ruling. The
strike left "the section above" pointing at the ADRIC rule set and "the
agreement" with no antecedent; both fixed. The bare designations line
sitting under ADRIC's quoted competence requirement is also struck, which
goes beyond the ruling and is flagged for Pouya.
R18 — re-stamped, two-tier: (a)(c)(d) re-verified against a source,
(b)(e)(f)(g) held on a cadence judgement. All seven hold, no shipped
sentence changed. R18's trigger had NO cutover checklist item and had
stamped five extracts of seven; both fixed. Candidate limb (h) flagged.
R10 — fired and unsatisfied; left open on instruction.
The evidence behind the new privacy sentence was weaker than the
sentence. Re-measured: 33 of 33 roles simulated (23 of 26 carried inline
policies nobody had read; the two CDK lookup roles can read the table),
four trust policies, the CloudFormation escalation path for all five
users, 0 federated providers, root recorded. Every read path terminates
at the same two people.
Two review rounds, 36 findings. 35 fixed, 1 declined. Five of round 2's
were defects in round 1's own fixes; stopped at two per D19.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Md3GndFqWPzK78xAoebsg5
This commit is contained in:
Pouya Lajevardi
co-authored by
Claude Opus 5
Claude Opus 5
parent
bd282aa47d
commit
6aaf089b05
+20
-4
@@ -386,11 +386,27 @@ the C.Med-Arb endpoint" until 2026-08-29; C.Med-Arb is off the site.)*
|
||||
Q.Arb, which is what med-arb requires. The page says he conducts med-arb and
|
||||
stops."* The section is **rewritten, not edited** — it earned its credibility
|
||||
from an incomplete credential and now says what med-arb demands of one
|
||||
neutral and that he holds both designations.
|
||||
neutral. ⚠️ **AND IT NO LONGER RESTATES THE DESIGNATIONS EITHER —
|
||||
2026-09-02, `claims-auditor` D20 pass, finding F.** §Why this practice held a
|
||||
bare `DESIGNATIONS_HELD_LINE` sentence sitting directly beneath §Rules'
|
||||
quotation of ADRIC requiring *"a high level of practitioner competence"*, so
|
||||
the designations read as meeting a bar ADRIC answers with the Chartered
|
||||
Med-Arb — struck from this site entirely. The section now makes **no
|
||||
credential claim at all**; `/about/` publishes them and the JSON-LD carries
|
||||
them. Do not reinstate one here.
|
||||
5. **The ADRIC Med-Arb Rules**, which this spec did not mention and which exist:
|
||||
a published rule set, presented to ADRIC's membership at its 2019 annual conference, drafted for domestic
|
||||
commercial disputes and designed to work with its Mediation and Arbitration
|
||||
Rules. Sourced: `docs/reference/adric-rules.md` Finding 2. Quote ADRIC's own
|
||||
~~a published rule set, presented to ADRIC's membership~~ — **CORRECTED
|
||||
2026-09-02, `claims-auditor` D20 pass, finding 6.** The source says a
|
||||
**discussion draft** was presented, not the rules; `adric-rules.md` Finding 2
|
||||
records no adoption and no effective date, in deliberate contrast to the
|
||||
Arbitration Rules ("effective March 1, 2025") and the Mediation Rules ("the
|
||||
existing rules remain in effect"). The page was corrected on 2026-09-01 and
|
||||
**this line still instructed the struck form for a day** — the Q.Arb lesson
|
||||
exactly: page fixed, spec still telling the next implementer to write the
|
||||
false version. Write it as **presented to the membership as a discussion
|
||||
draft at ADRIC's 2019 annual conference** — drafted for domestic commercial
|
||||
disputes and designed to work with its Mediation and Arbitration Rules.
|
||||
Sourced: `docs/reference/adric-rules.md` Finding 2. Quote ADRIC's own
|
||||
framing rather than paraphrasing it, and **keep its superlatives inside the
|
||||
quotation marks** — Finding 5 lists the two not to lift.
|
||||
|
||||
|
||||
@@ -211,7 +211,7 @@ against this row.
|
||||
| `submissionId` | `<uuid>` — **the partition key.** Fixed by the table; the notification email prints this value verbatim so it can be pasted into the console |
|
||||
| `submittedAt` | `<ISO-8601 timestamp>` — an ordinary attribute, not a sort key |
|
||||
| fields | as above |
|
||||
| `sourceIp`, `userAgent` | abuse investigation only |
|
||||
| `sourceIp`, `userAgent` | ~~abuse investigation only~~ — ⚠️ **AMENDED 2026-09-02: that purpose holds for `userAgent` and `submittedAt`, and NOT for `sourceIp`.** Behind the `/api/*` behaviour `requestContext.http.sourceIp` is a CloudFront edge, so it identifies the network rather than the sender and cannot serve an abuse investigation. `/legal/privacy/` now states the two purposes separately — timestamp and user-agent for abuse, the address as something that simply arrives with the request. **A spec and a page disagreeing about WHY data is held is the disclosure PIPEDA actually turns on**, and this row said one thing while the page said another for a day. `docs/09` Part 7.2 measures the field; if it holds the reader's own address, this row and that paragraph both change. `adversarial-reviewer`, round 2 |
|
||||
| `consentAt` | `<ISO-8601 timestamp>` — when the consent box was submitted |
|
||||
| `ttl` | epoch seconds — **the input to automatic deletion; see §Retention for why writing it is not the mechanism** |
|
||||
|
||||
@@ -446,7 +446,7 @@ Plausible or Fathom, cookieless, no consent banner.
|
||||
- [ ] **TTL set and verified by test record.** ⚠️ **THIS ONE BACKS A PUBLISHED PROMISE.** `/legal/privacy/` states that records are deleted automatically after 24 months, and it asserts the **mechanism**, not only the period. The handler writes the `ttl` attribute — epoch seconds, 24 months, confirmed against this spec `[verified 2026-08-31]` — and **writing the attribute is not the mechanism**: TTL must also be enabled on the table, which is a table setting the code cannot see. **`AGENTS.md` §7 holds that status and its stamp; this line does not restate it** — it restated it once, went stale within the day, and had to be pulled back (§12 R19). **The test record is what closes this item, not the status:** `ENABLED` proves the setting, a record written with a near-future `ttl` and observed to vanish proves the behaviour. Tracked as §9 Q60
|
||||
- [x] **PITR enabled** — `ENABLED`, 35-day window `[verified 2026-09-01 — describe-continuous-backups]`
|
||||
- [ ] KMS customer-managed key. **Not on the table: encryption at rest is with the AWS-owned key** `[verified 2026-09-01 — describe-table returns no SSEDescription]`. **Not claimed on `/legal/privacy/`** — the page says "encrypted at rest", which is unconditionally true of every DynamoDB table and does not mention a customer-managed key, so nothing published depends on it. An improvement, not a blocker
|
||||
- [ ] **Table access matches what `/legal/privacy/` says about it.** ⚠️ **IT DOES NOT, AS AT 2026-09-01.** The page says *"nobody else has access to the table… no external administrator"*; the account's `admins` group carries `AdministratorAccess` and has **two** members, and `simulate-principal-policy` returns **allowed** for `dynamodb:GetItem`/`Query`/`Scan` for both. Evidence and commands: `docs/reference/intake-table-access-verification.md`. §9 **Q62**, and it blocks that page going public
|
||||
- [x] ✅ **Table access matches what `/legal/privacy/` says about it — 2026-09-02.** **The access is unchanged; the page now states it.** Pouya ruled *state the truth* rather than *remove the access* (§9 Q62), so the page publishes two administrators of a shared account, and adds the two stronger facts the false sentence had crowded out: the handler role holds `PutItem` **only**, and `adr-sml-deploy` is `implicitDeny` on all seven read **and** write actions. Evidence and commands: `docs/reference/intake-table-access-verification.md`, whose enumeration was **extended on 2026-09-02** — the original screened roles by `list-attached-role-policies` alone, missing that 23 of 26 non-service-linked roles carry inline policies and that the two CDK `lookup` roles can read the table. Four roles can, not two; all four terminate at the same two people. ⚠️ **THIS LINE SAID "IT DOES NOT" FOR A DAY AFTER THE PAGE WAS CORRECTED, AND IT IS A DEFINITION-OF-DONE LIST SOMEONE FOLLOWS AT CUTOVER** — the Q62 sweep was run over `src/` only, so it could not reach a spec. `adversarial-reviewer`, round 1. The sweep across `docs/` is in the Change Log entry
|
||||
- [ ] Both emails send; SPF/DKIM/DMARC aligned; inbox-tested, not spam-tested
|
||||
- [ ] **CloudWatch alarms on Lambda `Errors` and API Gateway `5xx`** — replacing the DLQ item, which is struck: a DLQ on a **synchronously** invoked function never receives anything, so the alarm on its depth would have been permanently green. See §Notification. The handler writes to DynamoDB **before** sending mail, so the protection this item was pointing at is in the code rather than in a queue
|
||||
- [x] **Form usable by keyboard only.** Errors are announced by the browser's own validation, which with no script is the only thing that can announce them inline — `role="alert"` needs a live region and something to write into it
|
||||
|
||||
+124
-16
@@ -395,19 +395,49 @@ Then invalidate `/*`.
|
||||
> reversing them puts 22 of 23 pages behind a 403 for as long as a CloudFront
|
||||
> deployment takes.
|
||||
|
||||
> 🛑 **THREE THINGS BLOCK THIS ENTIRE LIST AS AT 2026-09-01, AND TWO OF THEM WERE
|
||||
> FOUND BY READING THE RUNNING SYSTEM RATHER THAN THE SPECS.**
|
||||
> 🛑 **TWO THINGS BLOCK THIS ENTIRE LIST AS AT 2026-09-02, AND ONE OF THEM IS A
|
||||
> WAITING PERIOD RATHER THAN A TASK.**
|
||||
>
|
||||
> 1. **`/legal/privacy/` states something false about who can read the intake
|
||||
> table** — §9 **Q62**, evidence in
|
||||
> `docs/reference/intake-table-access-verification.md`. A privacy policy is
|
||||
> the wrong page to be wrong on, and this one is wrong about third parties'
|
||||
> dispute information.
|
||||
> 2. **Q60 is still open** — TTL is `ENABLED` and no record has been watched to
|
||||
> disappear, and the same page asserts the mechanism. `docs/09` Part 10 is the
|
||||
> test and its answer arrives days after it starts, so **start it early**.
|
||||
> 3. **`claims-auditor`'s D20 pass returned six copy findings on 2026-09-01;
|
||||
> five are corrected and one is a ruling** — the `/med-arb/` gloss, below.
|
||||
> *(This said ONE for part of 2026-09-02, and that was a defect: the wording
|
||||
> approval Pouya reserved had been recorded only inside records marked closed —
|
||||
> the `TODO(pouya)` deleted, Q62 struck, this callout ticked — so when Q60 passed,
|
||||
> nothing would have stopped unapproved copy publishing. `adversarial-reviewer`,
|
||||
> D20 pass round 1.)*
|
||||
>
|
||||
> 1. **Q60 — the retention MECHANISM has still not been observed.** TTL is
|
||||
> `ENABLED` and no record has been watched to disappear, and
|
||||
> `/legal/privacy/` asserts the mechanism, not merely the period. `docs/09`
|
||||
> Part 10 is the test; its earliest useful reading is **48 hours** after the
|
||||
> record is written and it does not call failure before **7 days**, so
|
||||
> **start it before anything else on this page.** It is the one blocker that
|
||||
> is a waiting period rather than a task.
|
||||
> 2. **Q63 — `/legal/privacy/` needs two answers from Pouya**, both in the same
|
||||
> read-through: **(a)** approval of the §Who can see it wording, which he
|
||||
> reserved when he ruled Q62 (*"Pouya gives final approval on wording during
|
||||
> his page read-through"*), and **(b)** who else can read
|
||||
> `info@smlcompany.ca`, which this repository does not establish. (b) is
|
||||
> written so nothing false publishes either way; (a) is a straight gate. See
|
||||
> the unticked item under **Copy and claims** below.
|
||||
>
|
||||
> ✅ **CLOSED 2026-09-02 — Q62.** `/legal/privacy/` no longer states anything
|
||||
> false about who can read the intake table. Pouya's ruling was **state the
|
||||
> truth**, not remove the second administrator's access: the page now says two
|
||||
> people can read it, names their role, and adds the two stronger facts the
|
||||
> false sentence had been crowding out — the writing function cannot read the
|
||||
> table, and the deploy credential has no access to it at all. The
|
||||
> `sole-administrator-q62` tripwire in `check-claims.mjs` **stays permanently**
|
||||
> by the same ruling, extended from two alternatives to **five**: the clause the
|
||||
> first form could not see two sections up the same page, the summary that would
|
||||
> have re-asserted the struck number four lines below the corrected paragraph,
|
||||
> and the sentence that carried the false count. Proven both ways against the
|
||||
> pre-correction page rebuilt from `bd282aa` — **exit 1 with 5 matches**, exit 0
|
||||
> on the corrected page.
|
||||
> **Wording is subject to Pouya's read-through — §9 Q63(a), and it has its own
|
||||
> unticked item below.**
|
||||
>
|
||||
> ✅ **CLOSED 2026-09-02 — the `/med-arb/` gloss.** Struck, with no replacement
|
||||
> and no competence claim, per ruling. The ADRIC-sourced material carries the
|
||||
> section.
|
||||
|
||||
**Cutover prep — deferred maintenance, done BEFORE the checklist below**
|
||||
|
||||
@@ -464,8 +494,28 @@ the decision is re-readable rather than re-litigated.
|
||||
instruments its extract checked — and its own note then disclaimed that
|
||||
conclusion as the Commissioner's words; `/med-arb/` said the ADRIC Med-Arb
|
||||
Rules were presented to the membership where the source says a **discussion
|
||||
draft** was). Three remain and each has its own item below or above:
|
||||
the `/med-arb/` gloss (a ruling), Q60, and Q62.
|
||||
draft** was). ✅ **Two of the three remaining were ruled and closed
|
||||
2026-09-02** — Q62 (the page now states the measured truth) and the
|
||||
`/med-arb/` gloss (struck, no replacement).
|
||||
|
||||
⚠️ **AND THE PASS WAS RE-RUN OVER THOSE TWO FIXES ON 2026-09-02, WHICH IS
|
||||
WHAT MAKES THE ITEM CLOSEABLE — IT RETURNED FAIL WITH EIGHT MORE.** This is
|
||||
the same pass completing, not a per-step audit reinstated: a FAIL whose
|
||||
fixes are never re-audited leaves *"findings resolved"* asserted rather than
|
||||
checked. **Five of the eight were in the fixes themselves** — the
|
||||
replacement copy reintroduced an absolute third-party negative of the
|
||||
shape struck from this page on 2026-08-31, claimed an enumeration the
|
||||
evidence file did not support, asserted *"the one other place a copy
|
||||
exists"* when the inquirer's confirmation carries the whole submission,
|
||||
left `LAST_UPDATED` at 31 August on the change set that rewrote the page's
|
||||
central disclosure, and left *"your IP address"* standing when `docs/09`
|
||||
Part 7.2 had said in terms to fold it into the Q62 edit. Two were on
|
||||
`/med-arb/`: the struck gloss left *"the section above"* pointing at the
|
||||
ADRIC rule set and *"the agreement"* with no antecedent, and the bare
|
||||
designations line was left sitting directly under ADRIC's competence
|
||||
quotation. One was declined with a reason (§Rules' heading — see the
|
||||
Change Log). **All corrected or declined; the pass is clean on findings
|
||||
and the item is open only on the human halves above.**
|
||||
|
||||
**Two things about that result are worth carrying forward.** The pass found
|
||||
no defect in any claim about Pouya, his credentials or his designations —
|
||||
@@ -478,6 +528,26 @@ the decision is re-readable rather than re-litigated.
|
||||
have flagged correct copy and demanded the struck form. It read §4 instead.
|
||||
That is the fifth stale claim found in that file and it is not the agent's
|
||||
to fix
|
||||
- [ ] 🛑 **POUYA HAS APPROVED THE `/legal/privacy/` §Who can see it WORDING —
|
||||
§9 **Q63**(a).** Separate from the item below and narrower: Q62's ruling
|
||||
settled what that section must **say**; he reserved the **wording**. The
|
||||
draft is in `dist/` and quoted in
|
||||
`docs/reference/intake-table-access-verification.md`.
|
||||
⚠️ **THIS ITEM EXISTS BECAUSE THE GATE HAD NO MECHANISM.** On 2026-09-02
|
||||
the `TODO(pouya)` was deleted from the source, Q62 was struck in §9 and the
|
||||
blocker in the callout above was ticked — all correctly, and the net effect
|
||||
was that the only surviving record of an **open** approval requirement was
|
||||
prose inside three records marked ✅ CLOSED. When Q60's TTL test passes,
|
||||
nothing mechanical or visual would have stopped copy Pouya has not read.
|
||||
`adversarial-reviewer`, D20 pass round 1. The `TODO(pouya)` is reinstated
|
||||
beside the copy and §9 Q63 is open; this is the third surface, and it is
|
||||
the one a person following this list at cutover actually reads
|
||||
- [ ] **Q63(b) answered, or accepted as unanswerable** — who else can read
|
||||
`info@smlcompany.ca`. **Not a gate on truth**: the copy asserts no access
|
||||
list, so nothing false publishes either way. It is a gate on **standards** —
|
||||
the page answers the table half with a measured number and the mail half
|
||||
without one, and a reader is entitled to the specific on both. If he
|
||||
answers, the fact goes in §7 and §12 **R21**'s trigger covers it
|
||||
- [ ] **Pouya has read every page against `AGENTS.md` §4.** The human pass. It is
|
||||
the other half of D20 and it is not delegable — his reading is what the
|
||||
per-step audit was traded for.
|
||||
@@ -502,6 +572,29 @@ the decision is re-readable rather than re-litigated.
|
||||
**§4 records yearly renewal for the OBA sections and the CTF only** — it
|
||||
says nothing about ADRIC's or ADRIO's period, and an earlier version of
|
||||
this line asserted "all renew yearly", which §4 does not support.
|
||||
⚠️ **STILL OPEN AS AT 2026-09-02 AND IT IS A ONE-LINE ANSWER.** Pouya was
|
||||
asked on 2026-09-02. It is **one of three** items waiting on him that are
|
||||
not waiting periods — the other two are Q63(a)'s wording approval and his
|
||||
own read-through, both above; the earlier form of this line called it the
|
||||
only one, in a change set that added the other two
|
||||
(`adversarial-reviewer`, round 2). The question: *"are ADRIC, ADRIO, the three OBA sections and the
|
||||
CTF all still current?"* Answer it, then re-stamp §4 and `schema.ts` with
|
||||
the cutover date. Do not tick this from the 2026-08-28 stamp — a stamp is
|
||||
not a renewal receipt, which is the whole of R10.
|
||||
- [x] ✅ **THE SEVEN VOLATILE `docs/reference/` EXTRACTS RE-CHECKED — `AGENTS.md`
|
||||
§12 R18, whose trigger is the same "before any cutover" event R10 uses.** ⚠️ **THIS ITEM DID NOT EXIST UNTIL 2026-09-02 AND THAT
|
||||
WAS THE DEFECT**: R18 names a cutover as its trigger and the cutover
|
||||
checklist carried no item to fire it, which is Q22's shape — a documented
|
||||
control living somewhere it cannot run. R10 was on this list; R18 was not.
|
||||
**Re-checked 2026-09-01 by Pouya. All seven hold and no shipped sentence
|
||||
changed.** Three were re-verified against a source and four are held
|
||||
unchanged on a cadence judgement rather than a fresh retrieval — the
|
||||
distinction is stamped per limb in `AGENTS.md` §12 R18 and in each
|
||||
extract, because "re-checked" and "not looked at, judged slow" are not the
|
||||
same stamp and collapsing them is how OCNI lapsed.
|
||||
**Re-fire this on the next republish that turns on one of them**, and note
|
||||
that the fastest mover — Bill C-36 — needs no page edit while it sits at
|
||||
second reading and needs one the day it does not.
|
||||
- [ ] **The OBA sections stay listed; the LSO stays out** — a check that nobody
|
||||
has tidied the two into one list, not an open question. `AGENTS.md` **Q51
|
||||
answered 2026-08-28**: the Law Society is the **regulator**, so membership
|
||||
@@ -814,8 +907,23 @@ the decision is re-readable rather than re-litigated.
|
||||
Not a conformance failure of the same shape as Q61: a partial obscuring is
|
||||
not SC 2.4.11, which is about a component **entirely** hidden. `docs/02`
|
||||
§Reflow carries the 777-cell grid
|
||||
- [ ] ⚠️ **THE `/med-arb/` GLOSS NEEDS A RULING — `claims-auditor`, D20 pass,
|
||||
finding 1.** §Why this practice says *"Med-arb is not a third service
|
||||
- [x] ✅ **THE `/med-arb/` GLOSS — RULED AND STRUCK, 2026-09-02.** Pouya:
|
||||
*"strike the gloss sentence. The ADRIC-sourced material carries the page.
|
||||
No replacement claim, no competence claim."* Applied: the definitional
|
||||
gloss is struck. ⚠️ **AND SO IS THE DESIGNATIONS CLAUSE THAT THE FIRST
|
||||
VERSION OF THIS ITEM SAID WAS "NOW THE LEDE" — corrected 2026-09-02,
|
||||
`adversarial-reviewer` round 2, which found this line describing a page
|
||||
state the same change set had deleted.** Round 1 of the closing claims
|
||||
pass found that a bare `DESIGNATIONS_HELD_LINE` sitting directly beneath
|
||||
§Rules' quotation of ADRIC requiring *"a high level of practitioner
|
||||
competence"* read as meeting that bar. **§Why this practice now carries an
|
||||
acceptance sentence and no credential claim at all**; `/about/` publishes
|
||||
the designations and the JSON-LD carries them. The constraint is recorded
|
||||
in the section's own comment in `src/pages/med-arb.astro`. **The original
|
||||
finding is kept below unstruck**, because it is the reasoning behind a
|
||||
paragraph that is deliberately thin, and a later reader who cannot see why
|
||||
will fill it.
|
||||
`claims-auditor`, D20 pass, finding 1: §Why this practice said *"Med-arb is not a third service
|
||||
bolted onto mediation and arbitration; it is the two of them run under one
|
||||
agreement"*, and one section above the page publishes ADRIC's own words:
|
||||
med-arb is *"not merely the merging of separate mediation and arbitration
|
||||
|
||||
@@ -672,7 +672,7 @@ AWS address, not yours. Three outcomes and each has a different consequence:
|
||||
| what `sourceIp` holds | what it means |
|
||||
|---|---|
|
||||
| an **AWS** address (not the `checkip` value) | As designed. The field records the CDN, so it **cannot serve abuse investigation**, and `/legal/privacy/`'s *"your IP address"* is inaccurate — fold it into the Q62 edit on the same page rather than leaving two wrong sentences there |
|
||||
| **your** address, matching `checkip` | Better than expected, and worth knowing before anyone relies on it. Do not conclude it is trustworthy: verify it is not simply echoing a header by resubmitting with `-H 'X-Forwarded-For: 8.8.8.8'` and confirming `8.8.8.8` is **not** what lands |
|
||||
| **your** address, matching `checkip` | Better than expected, and worth knowing before anyone relies on it. Do not conclude it is trustworthy: verify it is not simply echoing a header by resubmitting with `-H 'X-Forwarded-For: 8.8.8.8'` and confirming `8.8.8.8` is **not** what lands. ⚠️ **AND CORRECT `/legal/privacy/` §What is collected**, whose network-address paragraph says the address is *"normally the network's own rather than your connection's"* — wrong in this branch, and it understates what is held about the reader. This row carried **no instruction at all** until 2026-09-02, so two of these three outcomes had nothing reconciling the page with the measurement (`adversarial-reviewer`, round 2) |
|
||||
| `8.8.8.8` after that resubmission | **Stop.** The field is client-controlled and a record can be made to name an uninvolved third party. Revert to storing nothing rather than storing that |
|
||||
|
||||
⚠️ **AN EARLIER REVISION OF THE HANDLER READ `x-forwarded-for` HERE, AND THAT WAS
|
||||
|
||||
@@ -13,6 +13,18 @@ cite it. Do not paraphrase a fact into a page that is not stated here.
|
||||
> date and effective date below is as at the retrieval date and nothing more.
|
||||
> Re-check before cutover, and before any republish that turns on one of them.
|
||||
|
||||
> ### R18 re-check — cutover pass, 2026-09-01
|
||||
>
|
||||
> The trigger fired. `AGENTS.md` §12 R18 holds the per-limb findings and
|
||||
> the sources; this stamp does not restate them. **The quoted bytes below
|
||||
> are still the original retrieval and were not re-fetched** — what was
|
||||
> re-checked is whether the *facts* they support have moved.
|
||||
>
|
||||
> - **(g) ADRIC's Code of Ethics, quoted verbatim on `/process/` — NOT
|
||||
> RE-RETRIEVED.** Held unchanged on a cadence judgement `[assumed
|
||||
> 2026-09-01 — Pouya]`. It is the slowest-moving of the seven; the live link
|
||||
> on `/process/` is what makes a stale quotation visible to a reader.
|
||||
|
||||
**Topic as researched:** The Canadian ADR institutions this practice names, and the exact form of their names — ADRIC / ADRIO rule sets, designations, codes; ADR Chambers; early neutral evaluation and dispute-system design
|
||||
|
||||
---
|
||||
|
||||
@@ -10,6 +10,19 @@ construction. This is the same fetch-before-writing that caught
|
||||
|
||||
**It caught one immediately. See Finding 1.**
|
||||
|
||||
> ### R18 re-check — cutover pass, 2026-09-01
|
||||
>
|
||||
> The trigger fired. `AGENTS.md` §12 R18 holds the per-limb findings and
|
||||
> the sources; this stamp does not restate them. **The quoted bytes below
|
||||
> are still the original retrieval and were not re-fetched** — what was
|
||||
> re-checked is whether the *facts* they support have moved.
|
||||
>
|
||||
> - **(f) the ADRIC National Mediation Rules, under review by ADRIC's own
|
||||
> committee — NOT RE-RETRIEVED.** Held unchanged on a cadence judgement
|
||||
> rather than a fresh fetch `[assumed 2026-09-01 — Pouya]`. The digests in
|
||||
> the Provenance table below are the 2026-08-28 bytes and were not
|
||||
> recomputed, so this stamp says nothing about whether the page changed.
|
||||
|
||||
## Provenance
|
||||
|
||||
| | |
|
||||
|
||||
@@ -21,6 +21,19 @@ not published.
|
||||
> at second reading on the retrieval date and could be law, or dead, by the time
|
||||
> anyone reads this. **Re-check before cutover.**
|
||||
|
||||
> ### R18 re-check — cutover pass, 2026-09-01
|
||||
>
|
||||
> The trigger fired. `AGENTS.md` §12 R18 holds the per-limb findings and
|
||||
> the sources; this stamp does not restate them. **The quoted bytes below
|
||||
> are still the original retrieval and were not re-fetched** — what was
|
||||
> re-checked is whether the *facts* they support have moved.
|
||||
>
|
||||
> - **(a) Bill C-36 — RE-VERIFIED UNMOVED** `[re-checked 2026-09-01 — Pouya,
|
||||
> <https://www.parl.ca/legisinfo/en/bill/45-1/c-36>]`. Still at second
|
||||
> reading in the House of Commons; latest completed stage is first reading,
|
||||
> 2026-06-15; no advance since. `/practice/technology/`'s sentence stands as
|
||||
> written.
|
||||
|
||||
**Topic as researched:** Canadian technology / data / AI dispute context — privacy legislation status as at 2026-08-29, Ontario public-sector and health privacy statutes, data residency law, and Canadian arbitral-institution rules for technology/AI disputes
|
||||
|
||||
---
|
||||
|
||||
@@ -10,16 +10,56 @@ one claim on the site whose subject was entirely outside the repo.
|
||||
|
||||
Raised by `claims-auditor` in the D20 cutover audit, 2026-09-01, finding 8.
|
||||
|
||||
**Provenance.** Every figure below was read from AWS on **2026-09-01** with the
|
||||
commands listed at the end, run read-only as `arn:aws:iam::327082975128:user/pouya`.
|
||||
**Provenance.** Figures in the ORIGINAL sections were read from AWS on
|
||||
**2026-09-01**; everything in the **2026-09-02 addendum** at the foot of this file
|
||||
was read on 2026-09-02, and it supersedes the original role screen. Both were run
|
||||
read-only as `arn:aws:iam::327082975128:user/pouya` with the commands listed at
|
||||
the end.
|
||||
No command in this file creates or changes anything. Re-run them rather than
|
||||
trusting this file; it is dated for that reason.
|
||||
|
||||
---
|
||||
|
||||
## The claim being checked
|
||||
## ✅ RULED AND APPLIED — 2026-09-02
|
||||
|
||||
`src/pages/legal/privacy.astro`, §Who can see it:
|
||||
**Pouya ruled `state the truth`, not `remove the access`** (§9 Q62, ruled
|
||||
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:
|
||||
|
||||
> 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.
|
||||
|
||||
> 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 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.
|
||||
|
||||
⚠️ **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.
|
||||
|
||||
---
|
||||
|
||||
## The claim being checked — ⚠️ STRUCK 2026-09-01, QUOTED HERE AS THE DEFECT
|
||||
|
||||
This is **no longer on the page.** It is kept because it is the string
|
||||
`check-claims.mjs`'s `sole-administrator-q62` pattern permanently bars, and a
|
||||
tripwire whose target is not recorded anywhere becomes unmaintainable.
|
||||
|
||||
`src/pages/legal/privacy.astro`, §Who can see it, **as it stood at `bd282aa`**:
|
||||
|
||||
> The table is reachable by the function that writes to it and by one
|
||||
> administrative account, which is mine — nobody else has access to the table.
|
||||
@@ -75,9 +115,13 @@ access, and it belongs to a second administrator of a shared account.
|
||||
`meshkini*`/`gitea*` users are evidence of that on the IAM surface, not just
|
||||
in the S3 bucket listing §10 describes.
|
||||
|
||||
## What has to happen before `/legal/privacy/` goes public
|
||||
## What had to happen before `/legal/privacy/` went public — ✅ RESOLVED BY OPTION 2
|
||||
|
||||
Tracked as `AGENTS.md` §9 **Q62**. It is one of two things and both are Pouya's:
|
||||
Tracked as `AGENTS.md` §9 **Q62**, **closed 2026-09-02 on option 2.** Kept
|
||||
unstruck because the reasoning is what makes the ruling re-readable, and because
|
||||
option 1 remains live in one direction: if that access is ever actually removed,
|
||||
the page and the tripwire both have to change, and `check-claims.mjs`'s `rule:`
|
||||
line carries that instruction.
|
||||
|
||||
1. **Remove the access** — take `lars` out of `admins`, or replace that
|
||||
membership with a policy that denies DynamoDB on this table — and then this
|
||||
@@ -139,3 +183,218 @@ parameter-expansion bug (`$ACCT:user/` parses `:u` as a history modifier). The
|
||||
loop above brace-quotes `${U}` for that reason, prints one line per principal so
|
||||
a silently-skipped iteration is visible as a missing row, and suppresses nothing.
|
||||
**Five rows, or the run did not happen.**
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 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.
|
||||
|
||||
*(This paragraph quoted a different sentence until 2026-09-02 — round 1's
|
||||
**pre-fix** wording, *"every account and role in this infrastructure…"*, which
|
||||
the audit then struck. So this file briefly quoted two different sentences as the
|
||||
live one, in the two halves of the same document, which defeats the comparison
|
||||
R14 exists for. Fixed by pointing at the block above rather than re-quoting it:
|
||||
one copy of a fact, in one place. `adversarial-reviewer`, round 2.)* Under R14 the artefact is what a reviewer compares the
|
||||
claim against, so a claim stronger than its artefact is unverifiable by
|
||||
construction even when it happens to be true.
|
||||
|
||||
**What was missing.**
|
||||
|
||||
1. **`aws iam list-role-policies` was never run.** The command block above lists
|
||||
only `list-attached-role-policies`, which returns *managed* policies. **23 of
|
||||
the 26 non-service-linked roles carry inline policies**, and none of them had
|
||||
been read. The screen for "broad policies" could not have seen an inline grant.
|
||||
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
|
||||
table at all"* covered three read actions and said "at all".
|
||||
|
||||
**What the measurement found, and it changes the role count.** Simulating all 26
|
||||
non-service-linked roles across **seven** actions — `GetItem`, `Query`, `Scan`,
|
||||
`BatchGetItem`, `PutItem`, `UpdateItem`, `DeleteItem`:
|
||||
|
||||
| role | decision on the table | trust |
|
||||
|---|---|---|
|
||||
| `cdk-hnb659fds-cfn-exec-role-…-ca-central-1` | **allowed on all 7** | `cloudformation.amazonaws.com` only |
|
||||
| `cdk-hnb659fds-cfn-exec-role-…-us-east-1` | **allowed on all 7** | `cloudformation.amazonaws.com` only |
|
||||
| `cdk-hnb659fds-lookup-role-…-ca-central-1` | **allowed on the 4 READS**, denied on writes | `arn:aws:iam::327082975128:root` |
|
||||
| `cdk-hnb659fds-lookup-role-…-us-east-1` | **allowed on the 4 READS**, denied on writes | `arn:aws:iam::327082975128:root` |
|
||||
| `adr-intake-lambda-role` | `PutItem` **only**; implicitDeny on the other six | `lambda.amazonaws.com` |
|
||||
| the other 21 | implicitDeny on all 7 | — |
|
||||
|
||||
**So FOUR roles can read the table, not the two this file recorded.** The two
|
||||
`lookup` roles were missed by exactly the gap above: their grant is the inline
|
||||
`LookupRolePolicy`, and `list-attached-role-policies` returns nothing for them.
|
||||
|
||||
**Why the published sentence is nevertheless correct.** The question is not how
|
||||
many roles exist but which *people* they lead back to.
|
||||
|
||||
- The two **cfn-exec** roles trust `cloudformation.amazonaws.com` and nothing
|
||||
else. No human can assume them; they are reachable only by deploying a
|
||||
CloudFormation/CDK stack, which requires a principal who can deploy one.
|
||||
- The two **lookup** roles trust the account root, which delegates the decision
|
||||
to the caller's own identity policy. Simulated for `sts:AssumeRole` against
|
||||
both role ARNs, for all five users, reading `ResourceSpecificResults` (ten
|
||||
per-resource decisions, not five — `EvaluationResults` is one entry per
|
||||
**action**, and an earlier pass here asserted the wrong count):
|
||||
|
||||
| principal | assume `lookup-…-ca-central-1` | assume `lookup-…-us-east-1` |
|
||||
|---|---|---|
|
||||
| `user/pouya` | **allowed** | **allowed** |
|
||||
| `user/lars` | **allowed** | **allowed** |
|
||||
| `user/adr-sml-deploy` | implicitDeny | implicitDeny |
|
||||
| `user/gitea-deploy-meshkinilaw` | implicitDeny | implicitDeny |
|
||||
| `user/meshkini-backend-deploy` | implicitDeny | implicitDeny |
|
||||
|
||||
- The **CloudFormation escalation path this file named and left untested** —
|
||||
*"a real path to the table for anyone who can deploy a CDK stack"* — is now
|
||||
measured. Simulated for `cloudformation:CreateStack`, `UpdateStack`,
|
||||
`CreateChangeSet`, `ExecuteChangeSet`, `iam:PassRole` and `sts:AssumeRole`,
|
||||
five users × six actions = **30 decisions**, count asserted:
|
||||
|
||||
| principal | the CDK / CloudFormation path |
|
||||
|---|---|
|
||||
| `user/pouya` | **allowed** on all six |
|
||||
| `user/lars` | **allowed** on all six |
|
||||
| `user/adr-sml-deploy` | implicitDeny on all six |
|
||||
| `user/gitea-deploy-meshkinilaw` | implicitDeny on all six |
|
||||
| `user/meshkini-backend-deploy` | implicitDeny on all six |
|
||||
|
||||
This is the finding that mattered most, because `meshkini-backend-deploy` is by
|
||||
its name another project's backend-deploy credential and
|
||||
`gitea-deploy-meshkinilaw` is held on a **jointly administered** Gitea instance
|
||||
(Q23). Either one, had it been able to drive CloudFormation, would have read
|
||||
the table without appearing in the five-row table above — and *"Two people
|
||||
can"* would have been wrong. Neither can.
|
||||
|
||||
- **And the seven roles every sweep here had excluded BY CONSTRUCTION are now
|
||||
measured too.** Every role loop in this file filters `grep -v
|
||||
'^AWSServiceRole'`, and the assertion was written as *"twenty-six role rows"* —
|
||||
so a service-linked role was outside the claim rather than inside it, which
|
||||
matters because a service-linked role for a backup or migration service can
|
||||
read table contents. All **7** (`APIGateway`, `CloudFrontLogger`,
|
||||
`InternetMonitor`, `RDS`, `ResourceExplorer`, `Support`, `TrustedAdvisor`) are
|
||||
**implicitDeny on all seven actions** — 49 decisions, count asserted
|
||||
`[verified 2026-09-02]`. **So the enumeration is 33 of 33 roles, not 26 of
|
||||
33**, and the page's *"every user and every role in the account"* is now
|
||||
literally true. Raised by `adversarial-reviewer`, round 2.
|
||||
|
||||
- **There is no federated identity surface at all**: `list-saml-providers` **0**,
|
||||
`list-open-id-connect-providers` **0**, `sso-admin list-instances` **0**
|
||||
`[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.**
|
||||
|
||||
**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
|
||||
`list-users`, so it cannot be simulated and no policy constrains it — root can
|
||||
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.
|
||||
|
||||
**Two page sentences are now supported that were not before.**
|
||||
|
||||
- *"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.
|
||||
|
||||
**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
|
||||
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.)*
|
||||
|
||||
⚠️ **THE INSTRUMENT FAILED FIRST, UNIFORMLY, AND IN THE DIRECTION THAT READS AS
|
||||
CLEAN.** The role sweep was first run as `--action-names $ACTS` with the seven
|
||||
actions in a shell variable. **zsh does not word-split parameter expansions**, so
|
||||
`simulate-principal-policy` received **one** action name — the whole string — and
|
||||
answered it: `implicitDeny` for 22 roles, and `allowed` for the four with a `*`
|
||||
grant, because `*` matches a bogus action too. Twenty-two clean rows and a
|
||||
plausible four. The tell was the shape of the output, not the verdict: one
|
||||
decision per role where there should have been seven. **The fix is the assertion,
|
||||
not the memory** — the loop now counts `EvaluationResults` per call and refuses a
|
||||
row that does not carry exactly seven, and the users' assume check counts
|
||||
`ResourceSpecificResults` and refuses a row that does not carry exactly two.
|
||||
`CLAUDE.md` records this class five times over; this is the sixth, and it is the
|
||||
"uniformly good" half.
|
||||
|
||||
### Commands — the ones this addendum rests on
|
||||
|
||||
Read-only, run as `user/pouya` in `ca-central-1`. No stderr suppressed, exit
|
||||
status read on every call, and note the **literal** action lists: they are not in
|
||||
a variable, which is the whole point above.
|
||||
|
||||
```bash
|
||||
# 1. Inline policies — the command the original block never ran.
|
||||
aws iam list-roles --query 'Roles[].RoleName' --output text \
|
||||
| tr '\t' '\n' | grep -v '^AWSServiceRole' \
|
||||
| while IFS= read -r R; do
|
||||
aws iam list-role-policies --role-name "$R" --query 'PolicyNames' --output text
|
||||
done
|
||||
|
||||
# 2. Every non-service-linked role, seven actions, decision asserted per row.
|
||||
# The count check is what makes a broken call loud instead of clean.
|
||||
aws iam simulate-principal-policy \
|
||||
--policy-source-arn "arn:aws:iam::327082975128:role/<ROLE>" \
|
||||
--action-names dynamodb:GetItem dynamodb:Query dynamodb:Scan \
|
||||
dynamodb:BatchGetItem dynamodb:PutItem dynamodb:UpdateItem \
|
||||
dynamodb:DeleteItem \
|
||||
--resource-arns "arn:aws:dynamodb:ca-central-1:327082975128:table/adr-intake-submissions" \
|
||||
--query 'length(EvaluationResults)' --output text # must print 7
|
||||
|
||||
# 3. Trust policies of the four roles that can read.
|
||||
aws iam get-role --role-name <ROLE> --query 'Role.AssumeRolePolicyDocument'
|
||||
|
||||
# 4. Who can assume the two lookup roles — per RESOURCE, not per action.
|
||||
aws iam simulate-principal-policy \
|
||||
--policy-source-arn "arn:aws:iam::327082975128:user/<USER>" \
|
||||
--action-names sts:AssumeRole \
|
||||
--resource-arns "arn:aws:iam::327082975128:role/cdk-hnb659fds-lookup-role-327082975128-ca-central-1" \
|
||||
"arn:aws:iam::327082975128:role/cdk-hnb659fds-lookup-role-327082975128-us-east-1" \
|
||||
--query 'EvaluationResults[].ResourceSpecificResults[].{R:EvalResourceName,D:EvalResourceDecision}' \
|
||||
--output text # must print 2 rows
|
||||
```
|
||||
|
||||
```bash
|
||||
# 5. The CloudFormation / CDK escalation path, per user. Six actions, literal.
|
||||
aws iam simulate-principal-policy \
|
||||
--policy-source-arn "arn:aws:iam::327082975128:user/<USER>" \
|
||||
--action-names cloudformation:CreateStack cloudformation:UpdateStack \
|
||||
cloudformation:CreateChangeSet cloudformation:ExecuteChangeSet \
|
||||
iam:PassRole sts:AssumeRole \
|
||||
--query 'EvaluationResults[].{A:EvalActionName,D:EvalDecision}' --output text
|
||||
|
||||
# 6. Federated identity surfaces, and root.
|
||||
aws iam list-saml-providers --query 'length(SAMLProviderList)'
|
||||
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}'
|
||||
```
|
||||
|
||||
**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.
|
||||
|
||||
@@ -13,6 +13,31 @@ cite it. Do not paraphrase a fact into a page that is not stated here.
|
||||
> date and effective date below is as at the retrieval date and nothing more.
|
||||
> Re-check before cutover, and before any republish that turns on one of them.
|
||||
|
||||
> ### R18 re-check — cutover pass, 2026-09-01
|
||||
>
|
||||
> ⚠️ **THIS FILE CARRIES THE STANDING RE-CHECK INSTRUCTION ABOVE AND WAS
|
||||
> NOT ONE OF R18's SEVEN LIMBS, AND IT WENT UNSTAMPED IN THE FIRST PASS.**
|
||||
> Five of seven extracts were stamped and two were not, so a reader could
|
||||
> not tell whether this one was considered and found non-volatile or simply
|
||||
> missed. Found by `adversarial-reviewer`, 2026-09-02 — the same
|
||||
> control-fires-over-part-of-its-scope defect as R18 having no checklist
|
||||
> item, one notch smaller. **Nothing here was re-retrieved.**
|
||||
>
|
||||
> - **No R18 limb, but ONE CANDIDATE LIMB, and it is flagged rather than
|
||||
> silently adopted.** `/practice/construction/` publishes: *"Ontario Power
|
||||
> Generation … applied in March 2026 for a licence to operate it."* That is a
|
||||
> **pending application**, so it moves the way limb (a) moves. It is not
|
||||
> false today — the application was made, and a completed past act stays
|
||||
> true — which is why this is a note and not a blocker. But a reader takes it
|
||||
> as current status, and unlike limb (a) the sentence is **not time-anchored**
|
||||
> ("when this page was written"). **For Pouya at the next re-check: adopt it
|
||||
> as R18 limb (h), or time-anchor the sentence and drop it.**
|
||||
> - The rest is stable: Part II.1 in force since 2019-10-01, and ODACC's own
|
||||
> statement that it is the Authorized Nominating Authority. The ODACC 2025
|
||||
> Annual Report is cited for institutional facts rather than for figures, so
|
||||
> it does not carry limb (d)'s exposure `[verified 2026-09-02 — swept
|
||||
> `dist/practice/construction/index.html`]`.
|
||||
|
||||
**Topic as researched:** Ontario construction dispute resolution — the statutory machinery (Construction Act, R.S.O. 1990, c. C.30); plus verification of the OPG Darlington New Nuclear Project and Bruce Power's Bruce C Project
|
||||
|
||||
---
|
||||
|
||||
@@ -13,6 +13,20 @@ cite it. Do not paraphrase a fact into a page that is not stated here.
|
||||
> date and effective date below is as at the retrieval date and nothing more.
|
||||
> Re-check before cutover, and before any republish that turns on one of them.
|
||||
|
||||
> ### R18 re-check — cutover pass, 2026-09-01
|
||||
>
|
||||
> The trigger fired. `AGENTS.md` §12 R18 holds the per-limb findings and
|
||||
> the sources; this stamp does not restate them. **The quoted bytes below
|
||||
> are still the original retrieval and were not re-fetched** — what was
|
||||
> re-checked is whether the *facts* they support have moved.
|
||||
>
|
||||
> - **(c) ERO 026-0853 — RE-VERIFIED UNMOVED** `[re-checked 2026-09-01 —
|
||||
> Pouya]`. The comment period to 2026-09-12 is still open.
|
||||
> - **(b) the regulation under `Electricity Act` s. 28.1 — NOT RE-RETRIEVED.**
|
||||
> Held unchanged on a cadence judgement rather than a fresh retrieval
|
||||
> `[assumed 2026-09-01 — Pouya: unchanged by its nature at this cadence]`.
|
||||
> That is a weaker stamp than (c) and is written weaker on purpose.
|
||||
|
||||
**Topic as researched:** Ontario electricity/energy regulatory processes that generate disputes: OEB leave to construct (OEB Act, 1998 ss. 90/92/95/96), the IESO and market participation, the IESO connection assessment process (SIA/CIA), large-load and data-centre grid connection (Electricity Act, 1998 s. 28.1), and Ontario Bill 40
|
||||
|
||||
---
|
||||
|
||||
@@ -13,6 +13,22 @@ cite it. Do not paraphrase a fact into a page that is not stated here.
|
||||
> date and effective date below is as at the retrieval date and nothing more.
|
||||
> Re-check before cutover, and before any republish that turns on one of them.
|
||||
|
||||
> ### R18 re-check — cutover pass, 2026-09-01
|
||||
>
|
||||
> The trigger fired. `AGENTS.md` §12 R18 holds the per-limb findings and
|
||||
> the sources; this stamp does not restate them. **The quoted bytes below
|
||||
> are still the original retrieval and were not re-fetched** — what was
|
||||
> re-checked is whether the *facts* they support have moved.
|
||||
>
|
||||
> - **(d) the Tribunals Ontario annual report — RE-VERIFIED UNMOVED**
|
||||
> `[re-checked 2026-09-01 — Pouya,
|
||||
> <https://tribunalsontario.ca/en/about/governance-and-accountability/>]`.
|
||||
> **No 2025-26 report is published; FY2024-25 remains current**, so the
|
||||
> figures `/practice/insurance/` publishes are still the latest. This closes
|
||||
> the open item at the foot of this file, which asked exactly that question.
|
||||
> - **(e) the SABS, amended with effect 2026-07-01 — NOT RE-RETRIEVED.** Held
|
||||
> unchanged on a cadence judgement `[assumed 2026-09-01 — Pouya]`.
|
||||
|
||||
**Topic as researched:** Ontario accident benefits (SABS) disputes — regulation, Minor Injury Guideline, the LAT-AABS dispute route, tribunal caseload volume, mediation references in tribunal materials, and FSRA's role
|
||||
|
||||
---
|
||||
@@ -341,6 +357,7 @@ honest, and on this project it is the half that has twice been skipped.
|
||||
- **Whether a more recent annual report than 2024-25 exists (i.e. a 2025-26 report covering the year ending March 31, 2026).**
|
||||
- *Searched:* WebSearch for Tribunals Ontario annual report LAT AABS caseload; retrieved the 2024-25 report, which is dated June 30, 2025 and is the most recent surfaced.
|
||||
- *Outcome:* NOT CONFIRMED either way. The 2024-25 report (fiscal year ending March 31, 2025) is the latest located as of 2026-08-29, but no search was run specifically to rule out a 2025-26 edition. Given today's date, one may well have been published. Re-check before publishing any 'most recent' or 'latest available' framing around these figures.
|
||||
- *Outcome, R18 re-check:* **CONFIRMED — no 2025-26 edition is published, and FY2024-25 remains current** `[re-checked 2026-09-01 — Pouya, <https://tribunalsontario.ca/en/about/governance-and-accountability/>]`. This closes the item as originally posed. The caution in the line above is retained rather than struck, because it is about a FRAMING and not about this fact: nothing on `/practice/insurance/` calls these figures the most recent or the latest available, and nothing should start to — a 2025-26 edition will appear eventually and a bare year label goes stale gracefully where a superlative does not.
|
||||
- **What the SABS amendments effective July 1, 2026 actually changed.**
|
||||
- *Searched:* Noted the consolidation banner on the e-Laws SABS page ('From July 1, 2026') and the tribunal's warning that 'Changes to the Statutory Accident Benefits Schedule effective July 1, 2026 may impact your insurance benefits'. Did not fetch O. Reg. 383/24 or the amending instruments.
|
||||
- *Outcome:* NOT ESTABLISHED. Search-result snippets suggested that certain benefits became optional, but no primary amending regulation was fetched, so nothing about the substance of the July 2026 changes is asserted here. The s. 3(1) definitions and the s. 18(1) $3,500 limit quoted above ARE from the post-July-2026 consolidation and are current as retrieved.
|
||||
|
||||
@@ -13,6 +13,22 @@ cite it. Do not paraphrase a fact into a page that is not stated here.
|
||||
> date and effective date below is as at the retrieval date and nothing more.
|
||||
> Re-check before cutover, and before any republish that turns on one of them.
|
||||
|
||||
> ### R18 re-check — cutover pass, 2026-09-01
|
||||
>
|
||||
> ⚠️ **THIS FILE CARRIES THE STANDING RE-CHECK INSTRUCTION ABOVE AND WAS
|
||||
> NOT ONE OF R18's SEVEN LIMBS, AND IT WENT UNSTAMPED IN THE FIRST PASS.**
|
||||
> Five of seven extracts were stamped and two were not, so a reader could
|
||||
> not tell whether this one was considered and found non-volatile or simply
|
||||
> missed. Found by `adversarial-reviewer`, 2026-09-02 — the same
|
||||
> control-fires-over-part-of-its-scope defect as R18 having no checklist
|
||||
> item, one notch smaller. **Nothing here was re-retrieved.**
|
||||
>
|
||||
> - **No volatile limb at this cutover.** The facts this file supports on
|
||||
> `/practice/shareholder/` are OBCA sections and case law, which do not move
|
||||
> at this cadence, and a sweep of the built page for dates, statuses and
|
||||
> "as of" framings returned nothing time-anchored `[verified 2026-09-02 —
|
||||
> swept `dist/practice/shareholder/index.html`]`.
|
||||
|
||||
**Topic as researched:** Ontario/Canada shareholder, partnership and closely-held business disputes — statutory remedies (oppression, dissent/appraisal, winding up), the Partnerships Act, arbitration references in the corporations statutes; plus an independent re-check of Ontario family arbitration training requirements.
|
||||
|
||||
---
|
||||
|
||||
+76
-28
@@ -259,28 +259,52 @@ const PATTERNS = [
|
||||
},
|
||||
{
|
||||
id: 'sole-administrator-q62',
|
||||
rule: 'Q62 — /legal/privacy/ claims sole administrative access to the intake table, and that is FALSE.',
|
||||
rule:
|
||||
'Q62 — the sole-administrative-access claim on /legal/privacy/ was FALSE ' +
|
||||
'and is permanently barred from returning. The page does NOT make it now; ' +
|
||||
'if this fired, something reintroduced the shape. ' +
|
||||
"⚠️ IF THE SECOND ADMINISTRATOR'S ACCESS IS EVER ACTUALLY REMOVED, this " +
|
||||
'pattern starts failing the build on TRUE copy, and the answer is neither ' +
|
||||
'to delete it nor to work around it: re-run the verification in ' +
|
||||
'`docs/reference/intake-table-access-verification.md`, rewrite the page to ' +
|
||||
'the new measured truth, and narrow THIS pattern deliberately with a ' +
|
||||
'Change Log entry. Q23 records the Gitea instance as jointly administered, ' +
|
||||
'so that removal is live rather than hypothetical.',
|
||||
incident:
|
||||
'The page shipped "nobody else has access to the table. There is no team, ' +
|
||||
'no assistant and no external administrator." The AWS account has an ' +
|
||||
'`admins` IAM group carrying AdministratorAccess with TWO members, and ' +
|
||||
'`simulate-principal-policy` returns allowed for dynamodb:GetItem, Query ' +
|
||||
'and Scan on the table for both ' +
|
||||
'[verified 2026-09-01 — docs/reference/intake-table-access-verification.md]. ' +
|
||||
'THE REACHED-DIST CONDITION IS WHY THIS PATTERN EXISTS AT ALL: the ' +
|
||||
'sentence was in dist/legal/privacy/index.html, `build`, `check` and this ' +
|
||||
'script all exited 0 over it, and the only thing between it and a live ' +
|
||||
'privacy policy was a TODO(pouya) in a JSX comment — which Astro strips, ' +
|
||||
'so `grep -rn "TODO(pouya)" dist/` returned nothing. The gate was human ' +
|
||||
'memory. Found by `adversarial-reviewer`, 2026-09-01. ' +
|
||||
'DELETE THIS PATTERN when Q62 is ruled: either the access is removed and ' +
|
||||
'the sentence becomes true, or the sentence is rewritten. It is a tripwire ' +
|
||||
'on one specific published falsehood, not a rule about a class.',
|
||||
/* `\s+`, NOT LITERAL SPACES: `compressHTML` collapses whitespace between
|
||||
tags and leaves it alone inside a text node, so the published bytes read
|
||||
"nobody else has access to\n the table". A literal-space version
|
||||
runs, prints `ok`, and exits 0 with the breach in `dist/`. */
|
||||
re: /nobody\s+else\s+has\s+access\s+to\s+the\s+table|there\s+is\s+no\s+team,\s+no\s+assistant\s+and\s+no\s+external\s+administrator/gi,
|
||||
'no assistant and no external administrator." while TWO principals could ' +
|
||||
'read it. It was in dist/, `build`, `check` and this script all exited 0 ' +
|
||||
'over it, and the only thing between it and a live privacy policy was a ' +
|
||||
'TODO(pouya) in a JSX comment — which Astro strips. The gate was human ' +
|
||||
'memory. Pouya ruled the pattern PERMANENT on 2026-09-01: it no longer ' +
|
||||
'describes live copy, it bars the shape. Do not delete it, and do not ' +
|
||||
'loosen it into a rule about a class. Full history: AGENTS.md entry (an).',
|
||||
/* THREE CONSTRAINTS, AND THEY ARE WHY THIS IS SHAPED AS IT IS.
|
||||
|
||||
1. `\s+`, NOT LITERAL SPACES. `compressHTML` collapses whitespace between
|
||||
tags and leaves it alone inside a text node, so the published bytes
|
||||
read "nobody else has access to\n the table". A literal-space
|
||||
version runs, prints `ok`, and exits 0 with the breach in `dist/`.
|
||||
|
||||
2. EACH ALTERNATIVE IS ONE STRING THAT REACHED `dist/`, NEVER A FAMILY.
|
||||
The first draft of alternative 3 was `(?:or|and)\s+(?:outside|external)`
|
||||
— four phrasings where one was published, so three had no probe and no
|
||||
negative fixture, which is the freeze's stated condition.
|
||||
|
||||
3. ALTERNATIVE 3 IS A DELIBERATE OVER-BAR AND THIS IS ITS COST. The
|
||||
truthful receipt-scoped sentence CONTAINS the published string, so any
|
||||
pattern catching one catches the other — adding that truthful form as a
|
||||
negative fixture failed the self-test, which is the instrument check
|
||||
working. So: the clause "no assistant or outside administrator" cannot
|
||||
be published here in ANY scoping, true or false, without failing this
|
||||
build. That is the right trade for a phrase that has already put a
|
||||
false statement on a privacy policy, and `rule:` says what to do. A
|
||||
lookahead tuned to one guessed phrasing would be the speculative
|
||||
pattern the freeze bars.
|
||||
|
||||
The window in alternative 5 is `[^\w<]{0,8}`, not `\W{0,8}`: `\W` matches
|
||||
`<` and the block sentinel, so it would have been bounded by neither. */
|
||||
re: /nobody\s+else\s+has\s+access\s+to\s+the\s+table|there\s+is\s+no\s+team,\s+no\s+assistant\s+and\s+no\s+external\s+administrator|no\s+assistant\s+or\s+outside\s+administrator|one\s+administrative\s+account,\s+which\s+is\s+mine|honest\s+answer\s+to\s+[^\w<]{0,8}who\s+can\s+see\s+this[^\w<]{0,8}\s*is:\s+me/gi,
|
||||
},
|
||||
];
|
||||
|
||||
@@ -367,23 +391,47 @@ const FIXTURES = {
|
||||
'C.Med-Arbitration',
|
||||
],
|
||||
'sole-administrator-q62': [
|
||||
/* The two published clauses, verbatim from dist/legal/privacy/. */
|
||||
/* The FIVE published clauses from dist/legal/privacy/ as it stood at
|
||||
`bd282aa`, before the Q62 correction. The first form of the pattern
|
||||
caught only the first two: clauses 3 and 4 are the same falsehood in
|
||||
different words in a different section, and clause 5 is the summary
|
||||
that would have re-asserted the struck number. */
|
||||
'nobody else has access to the table',
|
||||
'There is no team, no assistant and no external administrator.',
|
||||
'no analytics on the submission, and no assistant or outside administrator.',
|
||||
'The table is reachable by the function that writes to it and by one administrative account, which is mine',
|
||||
/* The third surface — the summary that would have re-asserted the struck
|
||||
number four lines below the corrected paragraph. */
|
||||
'So the honest answer to "who can see this" is: me, and Google as the company that runs my mail.',
|
||||
],
|
||||
'struck-universal-q39': [
|
||||
'Anyone may be appointed an arbitrator in Ontario',
|
||||
'nothing in law gates the role',
|
||||
],
|
||||
},
|
||||
/* Every one of these is real published or spec-approved copy on this site. */
|
||||
/* Mostly real published or spec-approved copy on this site. A few are
|
||||
deliberate NEAR MISSES — truthful sentences about the same subject that
|
||||
were never published — because a pattern also has to be proven silent on
|
||||
the wording a correction is likely to reach for. Where a fixture is one of
|
||||
those, the comment beside it says so. */
|
||||
mustNotMatch: [
|
||||
/* NEGATIVE FIXTURES FOR `sole-administrator-q62` — the approved copy nearest
|
||||
to the two clauses it catches. The pattern is deliberately anchored on the
|
||||
two published sentences rather than on the ideas in them, because the
|
||||
replacement wording is not yet decided and a looser pattern would fire on
|
||||
whatever Q62's ruling produces. These four are what "nearest" means: the
|
||||
same page's true sentences about the same subject. */
|
||||
/* NEGATIVE FIXTURES FOR `sole-administrator-q62`. The first three are the
|
||||
REPLACEMENT COPY ITSELF, verbatim from the corrected `/legal/privacy/` —
|
||||
which is the fixture that matters, because Q62's ruling required this
|
||||
pattern to be proven silent on the true sentence as well as loud on the
|
||||
false one. THEY MUST BE RE-SYNCED WHENEVER THAT COPY CHANGES — round 1's
|
||||
set went stale within the hour, when the audit rewrote three of the four
|
||||
paragraphs they were copied from. The rest are near misses on the same
|
||||
subject: the pattern is anchored on five strings that reached `dist/`, not
|
||||
on the ideas in them, so a truthful sentence about administrative access
|
||||
must pass. */
|
||||
'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.',
|
||||
'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.',
|
||||
'Two things in the system are narrower than I am, and they are worth stating because they are the part you cannot check for yourself.',
|
||||
'No one else is sent it. There is no CRM, no mailing list and no analytics on the submission.',
|
||||
'Which means there are three copies, not one. The notification in my own mailbox, which is on Google Workspace — so Google holds a copy of whatever you sent me, and so does anyone who can reach that mailbox.',
|
||||
/* The replacement summary, which must not trip the third-surface alternative. */
|
||||
'Which means there are three copies, not one. The record in the table, which the two people above can read.',
|
||||
'The table is reachable by the function that writes to it.',
|
||||
'Two accounts hold administrative access to the AWS account, and the function that writes to the table cannot read it.',
|
||||
'Nobody else has access to my mailbox.',
|
||||
|
||||
@@ -81,7 +81,7 @@ const RETENTION_MONTHS = 24;
|
||||
|
||||
/** Bump this on ANY substantive edit. A privacy policy with a stale date is a
|
||||
* policy a reader cannot tell they are reading an old version of. */
|
||||
const LAST_UPDATED = '31 August 2026';
|
||||
const LAST_UPDATED = '2 September 2026';
|
||||
|
||||
/* Rendered from the form's own field list, so the two cannot drift. `consent`
|
||||
and the honeypot are absent from `INTAKE_FIELDS` deliberately and are
|
||||
@@ -122,10 +122,30 @@ const COLLECTED = INTAKE_FIELDS.map((field) => field.label);
|
||||
<ul>
|
||||
{COLLECTED.map((label) => <li>{label}</li>)}
|
||||
</ul>
|
||||
{
|
||||
/* ⚠️ DO NOT WRITE "your IP address" HERE, AND DO NOT CONCLUDE ANYTHING
|
||||
ABOUT WHETHER THE ADDRESS IDENTIFIES ANYONE. The handler stores
|
||||
`requestContext.http.sourceIp` — behind the `/api/*` behaviour that
|
||||
is a CloudFront edge, so the expected value is Amazon's. **Expected,
|
||||
not measured:** `docs/09` Part 7.2 measures it at cutover and
|
||||
enumerates three outcomes, one of which is that the reader's own
|
||||
address does land. This copy therefore states only why the field is
|
||||
kept, which is true in all three. A previous form hedged "usually
|
||||
not yours" and then asserted "not precise enough to identify you" —
|
||||
false in exactly the branch the hedge admitted. `claims-auditor`,
|
||||
then `adversarial-reviewer` round 2. */
|
||||
}
|
||||
<p>
|
||||
Submitting the form also records the date and time, your IP address
|
||||
and your browser's user-agent string. Those three are kept for
|
||||
investigating abuse of the form and are not used for anything else.
|
||||
Submitting the form also records the date and time and your browser's
|
||||
user-agent string. Those two are kept for investigating abuse of the
|
||||
form and are not used for anything else.
|
||||
</p>
|
||||
<p>
|
||||
It also records the network address the request arrived from. This
|
||||
site sits behind a content delivery network, so that address is
|
||||
normally the network's own rather than your connection's — which is
|
||||
why it is kept simply because it arrives with the request, and not as
|
||||
a way of identifying anyone.
|
||||
</p>
|
||||
<p>
|
||||
Nothing else on this site collects personal information. There is no
|
||||
@@ -204,9 +224,10 @@ const COLLECTED = INTAKE_FIELDS.map((field) => field.label);
|
||||
what they keep.
|
||||
</p>
|
||||
<p>
|
||||
No one else receives it. There is no CRM, no mailing list, no
|
||||
analytics on the submission, and no assistant or outside
|
||||
administrator.
|
||||
No one else is sent it. There is no CRM, no mailing list and no
|
||||
analytics on the submission. Who can read what is stored is a
|
||||
different question from who it is sent to, and it is answered under
|
||||
"Who can see it" below.
|
||||
</p>
|
||||
|
||||
<h2>How long it is kept</h2>
|
||||
@@ -236,43 +257,76 @@ const COLLECTED = INTAKE_FIELDS.map((field) => field.label);
|
||||
|
||||
<h2>Who can see it</h2>
|
||||
{
|
||||
/* ⚠️ THIS SAID "Nobody else has access" AND THE SECTION TWO ABOVE HAD
|
||||
JUST NAMED GOOGLE. The Google correction was applied to §Where it is
|
||||
stored and not swept into the section actually headed with the
|
||||
question a reader asks — so the page answered "who can see the names
|
||||
of the opposing parties I gave you?" with *nobody else* under that
|
||||
heading and *Google* under a different one. Fixing one section and
|
||||
not the section that answers the same question is the sweep failure
|
||||
`CLAUDE.md` describes. Found by `adversarial-reviewer` round 2. */
|
||||
/* ⚠️ FIVE PARAGRAPHS ANSWER "WHO CAN SEE IT" AND THEY CHANGE
|
||||
TOGETHER: this section's four — the count, the measured enumeration,
|
||||
the two narrow credentials, the three copies — and §Where it is
|
||||
stored's last one. Every defect here has been a partial sweep of that
|
||||
set, and there have been four.
|
||||
**The enumeration paragraph is the one that goes stale on its own**,
|
||||
because it is a claim about the present state of an AWS account: §12
|
||||
**R21** is its trigger, and
|
||||
`docs/reference/intake-table-access-verification.md` holds the
|
||||
commands. `check-claims.mjs`'s `sole-administrator-q62` pattern is a
|
||||
permanent bar on the old shape returning (Pouya, ruled 2026-09-01). */
|
||||
}
|
||||
{
|
||||
/* TODO(pouya): the sentence below is FALSE as at 2026-09-01 and this
|
||||
page must not go public until you rule — §9 Q62. The AWS account has
|
||||
an `admins` IAM group carrying `AdministratorAccess` with TWO
|
||||
members, you and one other person, and
|
||||
`simulate-principal-policy` returns **allowed** for
|
||||
`dynamodb:GetItem`/`Query`/`Scan` on this table for both.
|
||||
Evidence and commands:
|
||||
`docs/reference/intake-table-access-verification.md`.
|
||||
THE QUESTION: do you remove that access — which may be the same
|
||||
co-administrator Q23's Gitea instance depends on, so it is not free
|
||||
— or does this paragraph state the true number? Nothing here may be
|
||||
softened into "authorised administrators": on this page a reader is
|
||||
entitled to the specific, and a true vacancy is worse than a false
|
||||
specific only in that it cannot be caught.
|
||||
Raised by `claims-auditor`, D20 cutover audit, finding 8. */
|
||||
/* TODO(pouya): TWO THINGS, BOTH FOR YOUR READ-THROUGH — §9 Q63.
|
||||
(1) APPROVE THE WORDING BELOW. Your ruling settled what it must say;
|
||||
you reserved the wording. Nothing else gates it.
|
||||
(2) WHO ELSE CAN READ `info@smlcompany.ca`? The paragraph below says
|
||||
"anyone who can reach that mailbox", which is true whatever the
|
||||
answer — but §7 records the mail host and the SES identities and NOT
|
||||
the mailbox's access list, so this repository cannot state the
|
||||
number a reader of a privacy policy is entitled to. If the Workspace
|
||||
is administered by anyone else, or the address is a shared alias,
|
||||
say so and this becomes specific like the table sentence above it.
|
||||
Raised by `claims-auditor` and `adversarial-reviewer`, D20 cutover
|
||||
pass, 2026-09-02. */
|
||||
}
|
||||
<p>
|
||||
I can. The table is reachable by the function that writes to it and by
|
||||
one administrative account, which is mine — nobody else has access to
|
||||
the table. There is no team, no assistant and no external
|
||||
administrator.
|
||||
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. I would rather tell you
|
||||
that than give you the tidier answer.
|
||||
</p>
|
||||
<p>
|
||||
The one other place a copy exists is the notification email, which
|
||||
sits in the Google Workspace mailbox named above. So the honest answer
|
||||
to "who can see this" is: me, and Google as the company that runs my
|
||||
mail.
|
||||
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. Amazon Web
|
||||
Services operates the table, as <em>Where it is stored</em> above says —
|
||||
a company that runs a database is not someone who has been given access
|
||||
to it, and both of those are true at once.
|
||||
</p>
|
||||
<p>
|
||||
Two things in the system are narrower than I am, and they are worth
|
||||
stating because they are the part you cannot check for yourself. The
|
||||
function that receives the form
|
||||
<strong>can only add a record — it cannot read the table back.</strong
|
||||
> And the credential that publishes this website has
|
||||
<strong>no access to the table at all</strong>, for reading or for
|
||||
writing.
|
||||
</p>
|
||||
{
|
||||
/* ⚠️ THREE COPIES, NOT TWO, AND THE THIRD IS THE READER'S OWN. This
|
||||
said "the one other place a copy exists" and named only my mailbox —
|
||||
while the handler puts the whole submission into the confirmation it
|
||||
sends the inquirer, under "What you sent:" (the second
|
||||
`SendEmailCommand` in `backend/intake/handler.mjs`). So a copy sits
|
||||
with the reader's provider, which §Where it is stored already tells
|
||||
them. An absolute enumeration standing one section from the page's
|
||||
own counter-example is what Q62 was; this is the same shape and it
|
||||
was introduced by Q62's own fix. Found by `claims-auditor`. */
|
||||
}
|
||||
<p>
|
||||
There are therefore three copies of what you send. The record in the
|
||||
table, which the two people above can read. The notification in my own
|
||||
mailbox, which is on Google Workspace — so Google holds a copy of
|
||||
whatever you sent me, and so does anyone who can reach that mailbox.
|
||||
And the confirmation that went to you, which sits with whoever runs
|
||||
your email; that copy is in your hands rather than mine.
|
||||
</p>
|
||||
|
||||
<h2>Cookies and analytics</h2>
|
||||
|
||||
+19
-25
@@ -25,7 +25,7 @@ import Undertaking from '../components/Undertaking.astro';
|
||||
import { getImage } from 'astro:assets';
|
||||
import ogDefault from '../assets/og-portrait.jpg';
|
||||
import { medArbGraph } from '../data/schema';
|
||||
import { CONDUCT_UNDERTAKINGS, DESIGNATIONS_HELD_LINE } from '../data/site';
|
||||
import { CONDUCT_UNDERTAKINGS } from '../data/site';
|
||||
|
||||
const ldImage = await getImage({
|
||||
src: ogDefault,
|
||||
@@ -61,7 +61,7 @@ const graph = medArbGraph({
|
||||
|
||||
<BaseLayout
|
||||
title="Med-Arb · Pouya Lajevardi · What It Is and When It Fits"
|
||||
description="Med-arb is mediation that converts to arbitration if it does not resolve. What it is, how it differs from arb-med, the fairness objection, and when it fits."
|
||||
description="Med-arb is mediation that converts to arbitration if it does not resolve. What it is, that it is not arb-med, the fairness objection, and when it fits."
|
||||
jsonLd={graph}
|
||||
>
|
||||
{/* ---- 1. Hero -------------------------------------------------------- */}
|
||||
@@ -238,38 +238,32 @@ const graph = medArbGraph({
|
||||
|
||||
{/* ---- 6. Why this practice -------------------------------------------- */}
|
||||
{
|
||||
/* ⚠️ THIS SECTION MUST NOT ANSWER THE ADRIC COMPETENCE QUOTATION ABOVE IT.
|
||||
For one pass it did: the heading read "Med-arb asks one neutral to be
|
||||
competent at both" — a restatement, in this site's voice, of ADRIC's
|
||||
"requires a high level of practitioner competence" quoted in the section
|
||||
immediately above — and the designations then answered it by adjacency.
|
||||
**The source answers its own sentence with a DIFFERENT designation**: the
|
||||
same ADRIC page points at the Chartered Med-Arb and a Med-Arb Foundational
|
||||
Course, and `docs/reference/adrio-designations.md` Finding 3 calls the
|
||||
Q-level designations "an intermediate step". So the page was borrowing a
|
||||
third party's competence standard and supplying an answer that party does
|
||||
not give. `claims-auditor`, round-2 audit, 2026-08-30 — the gloss lens.
|
||||
|
||||
The heading and lede now state what this practice holds and offers, with
|
||||
no competence proposition and no bridge to the quotation above. */
|
||||
/* ⚠️ THIS SECTION MAKES NO CLAIM ABOUT COMPETENCE AND NO CLAIM ABOUT WHAT
|
||||
MED-ARB IS, AND BOTH SILENCES ARE DELIBERATE. §Rules above quotes ADRIC
|
||||
requiring "a high level of practitioner competence", and ADRIC answers its
|
||||
own sentence with the Chartered Med-Arb and a Foundational Course —
|
||||
neither held, and C.Med-Arb is struck from this site entirely (§4). So
|
||||
anything in here that reads as meeting that standard is borrowing a third
|
||||
party's bar and answering it in this site's voice. That has now been
|
||||
removed three times: from the heading (2026-08-30), from the definitional
|
||||
gloss (Pouya's ruling, 2026-09-01) and from the bare designations line
|
||||
that was left sitting directly beneath the quotation (2026-09-02).
|
||||
**Do not refill this paragraph, and do not restate a designation here** —
|
||||
/about/ publishes them, and the JSON-LD carries them. */
|
||||
}
|
||||
<section class="section section-alt reveal">
|
||||
<div class="wrap">
|
||||
<div class="section-head">
|
||||
<SectionHeading eyebrow="Why this practice" level={2}>
|
||||
<span slot="heading">Both halves, in one practice.</span>
|
||||
<span slot="heading">Both processes, in one practice.</span>
|
||||
</SectionHeading>
|
||||
</div>
|
||||
<div class="prose">
|
||||
<p>
|
||||
{DESIGNATIONS_HELD_LINE}. Med-arb is not a third service bolted onto
|
||||
mediation and arbitration; it is the two of them run under one
|
||||
agreement, in the order the agreement sets.
|
||||
</p>
|
||||
<p>
|
||||
I accept med-arb appointments now, in commercial matters. The section
|
||||
above is the part to read before proposing one: the agreement does the
|
||||
work, and it does it before the mediation starts.
|
||||
I accept med-arb appointments now, in commercial matters. The three
|
||||
commitments above are the part to read before proposing one: the
|
||||
med-arb agreement does the work, and it does it before the mediation
|
||||
starts.
|
||||
</p>
|
||||
<p class="onward">
|
||||
<a href="/mediation/">Mediation →</a>
|
||||
|
||||
Reference in New Issue
Block a user