You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CHANGELOG.md
+27-8Lines changed: 27 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,6 +4,25 @@ All notable changes to this project should be documented in this file.
4
4
5
5
## Unreleased
6
6
7
+
## v0.4.3 - 2026-03-30
8
+
9
+
### Added
10
+
11
+
- a regulatory gold-set benchmark dossier plus advisory `regulatoryBenchmarkReadiness` reporting so manifest validation can surface benchmark-derived documentation gaps without pretending that research models are regulatory-grade
12
+
- a model-onboarding checklist that defines the trust pipeline for new PBPK chemicals and keeps internal use cases such as reference_compound out of the benchmark corpus
13
+
- a reproducible repo-concat generator for external review snapshots of the current PBPK MCP folder
14
+
15
+
### Changed
16
+
17
+
- trust-bearing summaries now carry clearer anti-misread, caution, benchmark-gap, and export-boundary surfaces across manifest validation, release audits, and OECD-oriented reporting
18
+
- release-prep documentation now reflects the current hardening work rather than the earlier packaged-runtime hotfix story
19
+
- the internal live-audit wording now treats the public release comparison as a moving baseline instead of hardcoding a stale public version label
20
+
21
+
### Fixed
22
+
23
+
- eliminated release-story drift between the codebase and the public-facing release metadata by aligning version markers, compose/env `SERVICE_VERSION`, README release notes, and the matching release note file
24
+
- verified that the live contract-manifest hash, packaged artifacts, and release-readiness gate all agree after a fresh redeploy
25
+
7
26
## v0.4.2 - 2026-03-22
8
27
9
28
### Fixed
@@ -154,9 +173,9 @@ All notable changes to this project should be documented in this file.
154
173
- optional `pbpk_run_verification_checks(...)` hooks for model-specific executable qualification checks such as mass balance and solver-stability heuristics
155
174
- stored `executableVerification` snapshots in `export_oecd_report` so OECD dossiers can carry the latest executed verification results without implicitly rerunning them
156
175
- parameter-catalog and parameter-table snapshots are now passed into `pbpk_run_verification_checks(...)` so model-specific runtime checks can validate exposed units and structural coverage
157
-
- executable structural physiology checks for systemic flow distribution and renal volume partition consistency in the cisplatin example model
158
-
- bounded local sensitivity evidence for the cisplatin example, exported through `uncertaintyEvidence` with current-parameter context rather than a placeholder sensitivity gap
159
-
- bounded variability-propagation evidence for the cisplatin example, exported through `uncertaintyEvidence` as a compact internal-exposure distribution summary
176
+
- executable structural physiology checks for systemic flow distribution and renal volume partition consistency in the reference_compound example model
177
+
- bounded local sensitivity evidence for the reference_compound example, exported through `uncertaintyEvidence` with current-parameter context rather than a placeholder sensitivity gap
178
+
- bounded variability-propagation evidence for the reference_compound example, exported through `uncertaintyEvidence` as a compact internal-exposure distribution summary
160
179
- explicit performance-evidence classification and qualification-boundary summaries in `export_oecd_report`, so runtime smoke/internal evidence is separated from predictive and external qualification evidence
161
180
- generic companion performance-evidence bundles for `.pkml` and MCP-ready `.R` models via files such as `model.performance.json`
162
181
- reusable starter template for companion performance-evidence bundles at `examples/performance_evidence_bundle.template.json`
@@ -172,12 +191,12 @@ All notable changes to this project should be documented in this file.
172
191
- release-readiness checks now exercise the executable verification surface in addition to validation, execution, and OECD report export
173
192
- executable verification now goes beyond smoke-only checks by asserting deterministic result integrity and repeat-run reproducibility
174
193
- OECD checklist/report generation now separates software-platform qualification evidence from implementation verification evidence
175
-
- the cisplatin example now contributes executable mass-balance and solver-stability checks through the runtime verification hook
194
+
- the reference_compound example now contributes executable mass-balance and solver-stability checks through the runtime verification hook
176
195
- OECD report export now carries stored executable verification snapshots separately from static `verificationEvidence`
177
-
- the cisplatin example now contributes executable parameter-unit consistency checks through the runtime verification hook
178
-
- the cisplatin example now contributes executable systemic-flow and renal-volume consistency checks through the runtime verification hook
196
+
- the reference_compound example now contributes executable parameter-unit consistency checks through the runtime verification hook
197
+
- the reference_compound example now contributes executable systemic-flow and renal-volume consistency checks through the runtime verification hook
179
198
- bridge evidence hooks now receive the loaded runtime parameter context and parameter-table snapshot so uncertainty/performance evidence can reflect the actual loaded model state
180
-
-cisplatin runtime smoke evidence is now explicitly labeled as internal operational evidence rather than implied predictive support
199
+
-reference_compound runtime smoke evidence is now explicitly labeled as internal operational evidence rather than implied predictive support
181
200
- static manifest inspection now treats a companion performance-evidence bundle as a valid alternative to a dedicated `pbpk_performance_evidence(...)` hook for `R` models
182
201
- companion performance-evidence bundles can now expose bundle-level metadata, and that metadata is surfaced through static manifest inspection and OECD report export
183
202
- malformed performance-evidence rows are now surfaced as warnings during static manifest inspection and OECD report export instead of being silently normalized
@@ -300,7 +319,7 @@ All notable changes to this project should be documented in this file.
300
319
### Fixed
301
320
302
321
-`.pkml` runtime execution for transfer files with empty `OutputSelections` via bounded observer fallback
303
-
- live discovery/index mismatch where custom models like cisplatin were loadable but not discoverable
322
+
- live discovery/index mismatch where custom models like reference_compound were loadable but not discoverable
304
323
- validation edge cases around scalar `contextOfUse` values
305
324
- async deterministic result retrieval with persisted fallback in `get_results`
This repository expects respectful, technically serious collaboration.
4
4
5
-
We are committed to providing a welcoming and respectful environment for everyone.
5
+
## Expected Behavior
6
6
7
-
Examples of behavior that contributes to a positive environment include:
7
+
- engage with ideas directly and in good faith
8
+
- keep criticism specific, factual, and constructive
9
+
- respect uncertainty, boundaries, and evidence limits
10
+
- help keep the project usable by scientists, engineers, and reviewers with different backgrounds
8
11
9
-
- Being respectful in communication.
10
-
- Giving and receiving constructive feedback.
11
-
- Focusing on what is best for the project and community.
12
+
## Unacceptable Behavior
12
13
13
-
Examples of unacceptable behavior include:
14
-
15
-
- Harassment, discrimination, or abusive language.
16
-
- Personal attacks, trolling, or insulting comments.
17
-
- Publishing private information without permission.
18
-
19
-
## Scope
20
-
21
-
This Code of Conduct applies in project spaces, including issues, pull requests, discussions, and related communication channels.
14
+
- harassment, abuse, or intimidation
15
+
- discriminatory language or personal attacks
16
+
- deliberately misleading technical claims
17
+
- sharing secrets, private data, or exploit details irresponsibly
22
18
23
19
## Enforcement
24
20
25
-
Project maintainers are responsible for clarifying and enforcing this Code of Conduct and may take action for behavior deemed inappropriate.
26
-
27
-
## Reporting
21
+
Maintainers may edit, moderate, or remove content that conflicts with this standard and may limit participation when needed to protect contributors or the project.
28
22
29
-
To report unacceptable behavior, open a private security advisory or contact the maintainers through the repository owner channels.
23
+
For sensitive cases, prefer a private contact path rather than escalating publicly.
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+35-30Lines changed: 35 additions & 30 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,46 +2,51 @@
2
2
3
3
Thanks for contributing to PBPK MCP.
4
4
5
-
## Development Setup
5
+
## Scope
6
6
7
-
1. Clone the repository.
8
-
2. Create a virtual environment.
9
-
3. Install dependencies:
7
+
This repository is a public PBPK MCP server with a published contract surface, live runtime checks, and release evidence gates. Contributions should preserve:
10
8
11
-
```bash
12
-
python -m pip install --upgrade pip
13
-
python -m pip install -e '.[dev]'
14
-
```
9
+
- contract clarity
10
+
- conservative scientific boundaries
11
+
- explicit auth and runtime safety
12
+
- reproducible release behavior
15
13
16
-
## Local Quality Gates
14
+
## Pull Requests
17
15
18
-
Run these before opening a pull request:
16
+
Before opening a pull request:
19
17
20
-
```bash
21
-
make lint
22
-
make type
23
-
make test
24
-
```
18
+
- run the relevant local tests for the area you changed
19
+
- update docs when behavior, contracts, or workflow expectations change
20
+
- avoid widening scientific or regulatory claims without explicit evidence and matching tests
21
+
- keep temporary files, credentials, machine-local paths, and generated runtime artifacts out of the patch
25
22
26
-
Optional heavier checks:
23
+
For release-facing or trust-surface changes, review:
27
24
28
-
```bash
29
-
make test-e2e
30
-
make compliance
31
-
make benchmark
32
-
```
25
+
-`docs/github_publication_checklist.md`
26
+
-`docs/hardening_migration_notes.md`
27
+
-`docs/pbk_reviewer_signoff_checklist.md`
28
+
-`docs/post_release_audit_plan.md`
33
29
34
-
## Pull Request Guidelines
30
+
## Model And Contract Changes
35
31
36
-
- Keep changes focused and small where possible.
37
-
- Add or update tests for behavior changes.
38
-
- Update docs when APIs, config, or workflows change.
39
-
- Include a concise summary and validation notes in the PR description.
32
+
If you change:
40
33
41
-
## Commit Style
34
+
- MCP tools or routes
35
+
- public schemas or examples
36
+
- trust-bearing summaries
37
+
- release or readiness checks
42
38
43
-
Conventional commit prefixes are recommended (`feat:`, `fix:`, `docs:`, `chore:`, `test:`).
39
+
also update the matching tests and generated contract artifacts.
44
40
45
-
## License
41
+
## Security And Scientific Claims
46
42
47
-
By submitting a contribution, you agree that your contributions are licensed under the Apache License 2.0 in this repository.
43
+
Do not:
44
+
45
+
- commit secrets, bearer tokens, or local credentials
46
+
- present runtime readiness as scientific adequacy
47
+
- present illustrative examples as regulatory-ready evidence
48
+
- remove caveats, block reasons, or scope boundaries from trust-bearing outputs without replacing them with something stronger
49
+
50
+
## Communication
51
+
52
+
Use issues and pull requests for normal changes. For sensitive security problems, follow `SECURITY.md` instead of opening a public issue with exploit details.
0 commit comments