Lucio Lelii
f5386cdb7e
The report now reads the per-subject sections the service produces: a row per iterated subject with what its labelled numbers did (Score 7 -> 4), the two texts behind it a click away, and the changed ones listed first. The band at the top leads with what the run actually did - whether the final decision changed, how many subjects moved, the largest delta - because the counts of changed nodes that used to open the report were the least actionable thing in it. A container's iterations are listed with the inner node that changed, which is what a per-subject iterator run needs and the accumulated list could never show. Reports produced before any of this exists still render, from their raw outputs. "Evaluate impact with LLM" sits next to the report it is about, in all three places one is mounted, and opens the provider and model picker the interaction simulator uses - extracted so both call the same dialog rather than two of their own, with temperature 0 offered by default because a verdict that reads differently every time it is asked for is worse than none. The assessment runs as a job, polled like the isolated experiment, and is stored on the report, so reopening it later shows the same verdicts and the model that produced them. It is labelled an assessment throughout, and a pair the model could not answer for is marked without hiding that pair's own figures. A rerun of a simulated run now opens the Simulate dialog on the simulator it inherited, with the inherited sampling out where it can be seen - a seed carried over is the reason the two runs are comparable, and behind a closed section nobody would find it. Before it is started, a run says which simulator the run it repeats used; afterwards, both the bias report and the run-to-run comparison say so when the two sides were not answered the same way, since that difference is not the intervention's doing and nothing said it. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .vscode | ||
| docker | ||
| docs | ||
| public | ||
| src | ||
| .dockerignore | ||
| .editorconfig | ||
| .gitignore | ||
| .postcssrc.json | ||
| Dockerfile | ||
| README.md | ||
| angular.json | ||
| components.json | ||
| nginx.conf | ||
| package-lock.json | ||
| package.json | ||
| tsconfig.app.json | ||
| tsconfig.json | ||
| tsconfig.spec.json | ||
README.md
HumAInFlow
This project was generated using Angular CLI version 21.0.3.
Development server
To start a local development server, run:
ng serveOnce the server is running, open your browser and navigate to
http://localhost:4200/. The application will automatically
reload whenever you modify any of the source files.
Code scaffolding
Angular CLI includes powerful code scaffolding tools. To generate a new component, run:
ng generate component component-nameFor a complete list of available schematics (such as
components, directives, or
pipes), run:
ng generate --helpBuilding
To build the project run:
ng buildThis will compile your project and store the build artifacts in the
dist/ directory. By default, the production build optimizes
your application for performance and speed.
Running unit tests
To execute unit tests with the Vitest test runner, use the following command:
ng testRunning end-to-end tests
For end-to-end (e2e) testing, run:
ng e2eAngular CLI does not come with an end-to-end testing framework by default. You can choose one that suits your needs.
Additional Resources
For more information on using the Angular CLI, including detailed command references, visit the Angular CLI Overview and Command Reference page.