Each Evaluation grows a componentSummary field — a small list of
plain strings, one per SKM ingredient (P / F / T / h), tagged
with its tier in the form 'P · T1 — DESTATIS Gewerbeanzeigen'.
The fixtures fill it in for all five pilot norms; the field
defaults to an empty list so flow-produced Evaluations remain
backwards-compatible until a future flow step writes one.
NormsListPage re-arranges the row to make use of the wide-screen
real-estate on the right that used to sit empty:
┌─────────────────────────────────────────────────────────────┐
│ GewO § 14 — Anzeigepflicht │ Schaden │ Komponenten │
│ eli/bund/gewo/14 │ 2.8 Mio € │ P · T1 … │
│ [T1 · amtlich] │ Nutzen │ F · T1 … │
│ │ 2.5 / 5 │ T · T1 … │
│ │ Betroffene │ h · T3 … │
│ │ 180 k │ │
└─────────────────────────────────────────────────────────────┘
The TierBadge moved into the title column (right under the eli)
so the eye lands on the tier of the figure right where the
figure's identity is named. The three metric columns stack
vertically (no more horizontal-only row) which leaves the right
third of the row free for the componentSummary lines — the
information a reviewer was always asking for ('which Komponente
is the bottleneck here?') is now visible without opening the
detail page.
Signed-off-by: flemming-it <sf@flemming.it>
Each of the five fixture Evaluations now carries a notes field
that breaks the lowest-tier-rule (Studie §6.7) into its four
SKM components (Population, Frequenz, Tarif, Zeitaufwand) and
names which one is the bottleneck. Tier markings stay
conservatively T4 on the surface — what changes is that a
reviewer reading the norm-detail panel now sees:
- which Komponenten are real T1 numbers (DESTATIS-derived P,
Verdiensterhebung-T) vs. where the demo extrapolates
- which Komponenten still wait on NKR-Validierung (mostly h)
- the political bottom line per norm: GewO §14 needs an
NKR-h-Wert; KassenSichV is largely documented; DSGVO Art.30
is EU-bound, reform-Hebel sits in Brüssel; BauO Bln §60 is
Land-domain without Bundes-NKR support; MiLoG §17 is under
Bürokratieentlastungsgesetz-IV-Bewegung.
No data-model change. Same fixtures, more honest reading.
Signed-off-by: flemming-it <sf@flemming.it>
Adds the actual paragraphs of the law right next to the
evaluation panel on the norm-detail page. A reviewer no longer
has to leave the app to confirm what a score is about; the
canonical source URL stays one click away via 'Im Browser
öffnen' (url_launcher) and one click away as a clipboard copy.
Schema
models.dart gains a NormParagraph (number + text). Norm carries
a List<NormParagraph> paragraphs, defaulted to const [] so
norms harvested by text.akoma_normalize@^0 in live mode slot
in without breaking the Mock path.
Demo data
fixtures.dart embeds the public source paragraphs verbatim
under §5 UrhG (amtliche Werke) for the five pilot norms.
Plumbing
NormTextCard (lib/widgets/norm_text_card.dart) is the renderer:
per-paragraph hanging label, selectable body text, source URL
in mono at the bottom, two action buttons. NormDetailPage
drops the card between the metric row and the duties card so
the eye lands on it during a 'why this score?' read-through.
macOS sandbox
The Release entitlement file gains
com.apple.security.network.client so url_launcher's NSWorkspace
call and the HubRepository's gRPC channel can both reach the
network. The DebugProfile already had server; client matches
the production posture.
GeneratedPluginRegistrant.swift was re-generated by
flutter pub get after url_launcher was added — no hand edits.
flutter analyze: clean. flutter test: 2/2 passing. The macOS
build via build-macos.sh launches and the new card renders the
GewO § 14, KassenSichV, DSGVO Art. 30, BauO Bln § 60 ff and
MiLoG § 17 fixtures with their actual normative text.
Signed-off-by: flemming-it <sf@flemming.it>
First end-to-end-buildable cut of the pflicht-/graph-basierte
Wirkungsanalyse von Rechtsnormen, running on Ch∆In. Demo runs
without external dependencies and without a hub connection so
the methodology + UI stack can be reviewed before any Verbands-
Kooperation or Beirats-Validierung kicks in.
Tree layout
MACHBARKEITSSTUDIE.md v0.3 — pflicht-basierte Methodik,
4-Tier-Evidenz, 8 law*-Module
auf Ch∆In statt der alten F∆I-
Plattform.
RUN.md one-page how-to-run.
flows/durchstich-gewo-14.yaml
vertical Phase-0 flow: pull →
normalize → duties → citations →
cohort → skm → frust → benefit →
attribution → system.approval.
app/ Flutter macOS client, design
language pulled from fai_web
(ink #08090A, paper #F4F3EF,
petrol signal #2E8F9E). Mock
repository ships five fixture
norms with real source URLs and a
permanent T4 demo-banner so no
figure can be mistaken for a
validated one.
Module repos (separate, see chain-modules*/):
text-akoma-normalize, text-deontic-extract, graph-citation-
extract, text-readability-score, stats-cohort-size, graph-
shapley-attribution, econ-skm-score, law-benefit-score.
What runs today
- flutter analyze: 0 issues
- flutter test: 2/2 (landing + nav-to-shell smoke)
- flutter build macos (via app/build-macos.sh) and ad-hoc
codesign, app launches and the Dart VM service comes up
- native cargo test green on every module
- cargo build --release --target wasm32-wasip2 produces a
130 KiB artefact for text-akoma-normalize
What is deliberately mock / stub
- gRPC wire from the client to a chain serve hub (Repository
abstraction is in place; live impl is the next step)
- NKR Bürokratiekosten-Datenbank ingestion (for the canonical
h-Werte that close out the Engpass per Studie §6.7)
- DESTATIS GENESIS-API adapter for stats.cohort_size
License: Apache-2.0. Author/contact in MACHBARKEITSSTUDIE.md.
Signed-off-by: flemming-it <sf@flemming.it>
