tegwick
7f135f9e0f
Operator ruling: no external determination in build mode, but keep the set of legal policies for reuse when a work context needs one in place. docs/regulatory/policies/ catalogues thirteen, keyed by activation condition rather than by regime, with a retrieval table so a context pulls a slice: first real user account pulls six of them; a consumer-facing product in Germany pulls those plus accessibility. Two are already active and nobody had noticed — commercial and tax retention, and the e-invoicing receiving obligation that has been live since 2025 with no named owner in the estate. Four written in full; the rest carry their trigger now and get their text when a context approaches, which is the point. RISK-POL-0011 is the argument for the whole catalogue: accessibility cannot be retrofitted cheaply, so a policy retrieved at launch is a rebuild while one read at design time is just a constraint. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| policies | ||
| audit-retention-basis.md | ||
| README.md | ||
Regulatory intake
Moved here from policy-nexus on 2026-08-17: deciding what an external rule
demands of the estate is a judgement about risk, not an act of publishing.
One file per question. Each record states what a source says and when, and
what the estate therefore relies on. What the estate must consequently do is
the owning repo's decision, not this repo's — INTENT.md.
A record carries sources_read, determined, external_review (usually
none, and it must say so rather than implying otherwise), and review_by.
A regulatory answer expires; that is why it is dated and reviewed rather than
consulted once and discarded, which is the failure that moved this remit here.
These records are not legal advice and this repo cannot make them into any. Where a position is weak, the record says which part and why.
| Record | Question | Finding |
|---|---|---|
audit-retention-basis.md |
On what basis are audit records retained against an erasure request? | RISK-F-0008 |
Routing a regulatory question here
RISK-WP-0003-T03. audit-core did this correctly on 2026-08-18 without a
route existing, so the route is theirs written down rather than invented.
Send a message to risk-nexus containing:
- The question, as a question. Not what you think the answer is.
- What you have already decided that depends on it.
audit-corenamedR4as unreachable by design and said the exemption had been assumed — that sentence is what made the question filable. - What becomes expensive if the answer is no. This is the field that sets urgency. Their answer — that encrypt-then-hash is not retrofittable onto events already accepted — is why the question could not wait.
- What you are not asking for. They asked for an owner, not a legal opinion. That boundary made it answerable.
What you get back: a dated record in this directory stating what the sources say, which ground the estate relies on, where the position is weak, and what would change it. Plus a finding, if the answer changes what anyone should do.
What you will not get: legal advice, or a ruling on what your repo must
therefore do. INTENT.md keeps the second with you. A regulatory record states
the constraint; the response to it is the owning repo's design decision.
If nobody answers, the wait is typed with a default and a date like every
other (docs/method/dependencies.md). The register will not hold your question
open indefinitely and call that progress.