RS2: Make profile-runtime service contracts executable and validate injected service graphs - #362
Conversation
Record the Phase A trust model, common composition validation, result ordering, hostile cases, and verification boundary required for issue #160 before runtime implementation.
samovers
changed the title
Exact-head Phase A review requestedPlease review only exact head Contract identity: RFC identity: Phase A changes exactly one path: Please classify each finding as Blocker, Follow-up, or Preference under Phase B must not begin until this exact head has a zero-Blocker Phase A review |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #362 — Phase A review
Reviewed exact head:
4de682c493ae2d39cd29ae6c897f928791a14a57
against base/current main:
0c55f5cc6665ffef4c57591dafe014ad9bc44524
The PR is correctly limited to one new Phase A RFC and contains no runtime implementation.
Disposition
Request changes: 3 Blockers, 1 required trust-model clarification, and 1 metadata correction.
Do not approve this Phase A contract or begin Phase B on the current head. The direction is sound, but the proposed validator still admits service graphs that can fail late or execute a cross-profile service.
Blocker 1 — the signature matrix does not test the calls the runtime actually makes
The RFC proposes validating one maximally populated call per method using inspect.signature(...).bind(...). That proves the callable accepts the supplied arguments; it does not prove that parameters omitted by real callers have defaults.
For example, this implementation passes the proposed matrix:
def assemble(
self,
cur,
farm_ref,
*,
target_twin,
evaluation_time_policy,
):
...because the matrix supplies both keyword arguments. But the real applicability gate calls:
assemble(ctx.cur, ctx.farm_ref)and therefore raises a late TypeError.
The same defect exists for materialization. The proposed matrix supplies twin and time_policy, while the real MaterializationGate calls recompute(ctx.cur, ctx.farm_ref) without either argument.
It is also present on the output boundary: the live HTTP routes call passport_view(farm_ref, party_ref) and freeze_document_assembly(farm_ref, party_ref, start, end) without the optional flags that the RFC’s matrix always supplies. A provider making those flags required would pass composition and fail at the endpoint.
The call inventory is additionally incomplete around recomputation. The concrete materializer accepts use_class, and resolve_for_use() calls recompute(..., use_class=...), but the proposed ProfileMaterializer.recompute contract and matrix omit that keyword.
Required correction
Replace the “one maximal shape per callable” model with an inventory of every production-reachable call form. At minimum, admission must bind:
- the minimal calls made by the applicability gate, materialization gate, and API routes;
- the keyword-rich calls made by materialization and output internals; and
- any call that depends on a declared default.
For a method with both forms, bind both. Add negative tests in which a nominally optional parameter is made required and prove composition refuses it before transaction entry. Align the recompute protocol with the actual supported use_class call or explicitly document and test why that call is outside the service contract.
Until then, PRSC-001 and PRSC-007 are false: a graph can pass admission and still produce the same late TypeError this ticket exists to eliminate.
Blocker 2 — registry reverification has no executable return contract
ProfileRegistryReverification declares only a callable run(context); it does not define or enforce the result as GateRefusal | None.
The generic validation gate currently interprets the result using ordinary truthiness:
refusal = validator.run(ctx)
if refusal:
return refusalIt then logs VALIDATION/PASS if the value is falsey.
This creates two production-reachable malformed-result paths:
def run(self, context):
return {}A falsey dictionary is treated as successful registry validation, and VALIDATION/PASS is logged.
def run(self, context):
return {"refuse": True}A truthy dictionary is returned from ValidationGate, but the pipeline only branches on an actual GateRefusal. It therefore continues through the remaining chain with no valid validation outcome.
Signature inspection cannot detect either case. A malformed provider-controlled validator result can therefore be interpreted as success or ignored while the commit continues. That contradicts the RFC’s promise that malformed service behavior becomes an explicit ProfileRuntimeError, and it violates the existing deterministic gate-result discipline.
Required correction
Define the private result contract as exactly:
None | GateRefusal
Validate it in ValidationGate before truthiness or control-flow interpretation. Any other value, including falsey mappings, arbitrary objects, and GatePass, must raise ProfileRuntimeError and roll back the transaction.
Required hostile tests should cover at least:
{};- a non-empty dictionary;
- an arbitrary falsey object;
- an arbitrary truthy object; and
GatePass.
The tests must prove no promotion, no successful validation entry, and no durable effects survive.
This requires adding kernel/validators.py and relevant tests to the approved Phase B boundary. The current RFC does not permit that file, so the contract itself must be amended before implementation.
Blocker 3 — the “complete graph” validator leaves the registry service cross-wirable
The RFC identifies as a protected asset the exact relationship between the Store-bound descriptor and every service in the executable graph. But PRSC-003 binds only:
- policy;
- context;
- materializer;
- output assembler;
- materialization/output specifications; and
- policy references.
It contains no descriptor or profile binding for registry_reverification.
That service is not profile-neutral data. The SI provider constructs it with the SI REGSR snapshot prefix and an SI product lookup. The validator itself retains those profile-specific objects and uses them during operation validation.
Consequently, this graph satisfies every stated PRSC-003 check:
bad = replace(
synthetic_services,
registry_reverification=si_services.registry_reverification,
)It still has:
- the exact outer dataclass;
- the exact synthetic descriptor;
- correctly bound policy, context, materializer, and output services;
- exact specification identities;
- a valid
run(context)signature; and - correct synthetic policy references.
Yet an operation claim executes the SI registry snapshot family and SI product lookup inside a nominally synthetic/non-SI graph. That is precisely the cross-profile reuse the common validator is supposed to prevent.
Required correction
Give every profile-owned executable registry-reverification service an explicit binding to the exact selected descriptor. The smallest clear contract is an active_profile or descriptor attribute checked by object identity against the Store-bound descriptor.
Then add a hostile test replacing only the registry-reverification service with one from another profile and require composition-time refusal.
This likely requires narrow changes to:
kernel/profile_runtime_services.py
kernel/profile_runtime_provider.py
kernel/validators.py
kernel/profiles/si_ffs/runtime_provider.py
kernel/tests/_synthetic_profile_runtime.py
focused tests
That does not create a universal ProductRegister abstraction. It merely binds an existing capability-specific executable service to the profile whose reference semantics it applies.
Because kernel/validators.py and the SI provider are outside the current approved file list—and the RFC says an out-of-boundary non-mechanical change is a stop condition—the Phase B boundary must be amended and independently re-reviewed.
Required trust-model clarification — explicit injection skips the source-admission state
The trust model says a provider becomes trusted to execute only after both source admission and graph validation. The state machine, however, permits:
EXPLICIT_INJECTION_CANDIDATE
-> graph validation
-> COMPOSED
and explicitly says the injection path performs no provider import.
The common graph validator can establish object coherence; it cannot establish where the executable classes came from.
The contract should say one of the following explicitly:
- production injection is only an internal handoff of a graph already returned by the source-admitted loader, while arbitrary injection is test-only; or
- the trusted composition caller owns source provenance for explicit injection, and D22/#240 source admission is not being claimed for that path.
This can probably be fixed as wording rather than new machinery. Leaving it ambiguous makes the authority map claim more than the proposed validator can prove.
Metadata correction — the RFC names the wrong repository-pinned Python
The Phase A evidence section calls Python 3.14.5 “repository-pinned” and points to an unrelated absolute issue-171 worktree path.
The repository pin is:
3.12.13
The PR description itself correctly reports 3.12.13.
Correct the RFC to record the interpreter actually used, label it unsupported/non-authoritative when it differs from 3.12.13, and remove the unrelated machine-specific path from the durable contract. This is not a separate design blocker because that observation is already disclaimed as acceptance evidence, but the provenance record must still be accurate.
What is otherwise correct
The PR has the right architectural direction:
- It does not reopen the model/runtime split or alter active OFARM law.
- It correctly classifies the work as an implementation/conformance implication, not baseline law.
- One graph validator for provider-loaded and explicitly injected graphs is preferable to the current duplicate, weaker injection check.
- Consumer-side validation of
contextSnapshotId,basisRef, andsnapshotRefbefore success logging is correctly placed. - Treating malformed provider results as implementation failures and relying on transaction rollback is appropriate.
- Exercising the synthetic service graph through the real generic stages is materially stronger than direct fixture calls.
- The non-goals around Serbia activation, public plugins, schema changes, manifests, evidence lanes, and canonical law are appropriate.
Authority impact
Active baseline files affected: none.
Change category: implementation/conformance RFC correction.
Smallest controlled next patch: amend only this Phase A RFC to fix the three executable-contract gaps, update the Phase B file boundary, and correct the evidence wording. Then request another exact-head Phase A review.
Final review result: Phase A is not ready for approval; Phase B must not start from head 4de682c493ae2d39cd29ae6c897f928791a14a57.
Revised exact-head Phase A review requestedPlease review only exact head Contract identity: RFC identity: This revision addresses every finding from the review of
Phase A still changes exactly one path: Verification at this head:
Please state whether each prior finding is cleared and classify any new finding |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #362 — focused exact-head re-review
Reviewed exact head:
c47639972fc26a8bad72a212aafb5c0fb706f710
against base/current main:
0c55f5cc6665ffef4c57591dafe014ad9bc44524
The PR remains a draft, documentation-only Phase A change with one changed file.
Disposition
1 Blocker.
The revision closes the registry-result blocker, registry cross-binding blocker, explicit-injection provenance clarification, and Python-version metadata correction. The call-form blocker is mostly corrected, but one production-reachable default-dependent call remains absent from the inventory.
Phase B should not begin from this head.
Blocker — the zero-argument evidence_policy() call is still not admitted
The revised call-form inventory independently checks minimal and keyword-rich calls for context assembly, recomputation, materialization resolution, and output assembly. That correctly fixes most of the earlier signature-admission problem.
For the policy service, however, it includes only:
evidence_policy(supported_checks=value)
validation_policy()
It does not include:
evidence_policy()
That zero-argument call is production-reachable today. The current DescriptorPolicyProvider.validation_policy() implementation delegates internally as follows:
def validation_policy(self) -> dict:
return self.evidence_policy()["validation"]The service protocol also currently presents supported_checks as optional:
def evidence_policy(self, supported_checks=None) -> dict: ...A provider can therefore satisfy every revised composition check and still fail after composition:
class CandidatePolicy:
descriptor = selected_descriptor
policy_ref = selected_descriptor.evidence_policy_ref
recognized_rule_refs = required_rules
def evidence_policy(self, supported_checks):
return {"validation": {}}
def validation_policy(self):
return self.evidence_policy()["validation"]Composition behavior:
evidence_policy(supported_checks=value) -> binds
validation_policy() -> binds
all descriptor/policy checks -> pass
Runtime behavior:
ValidationGate
-> validation_policy()
-> evidence_policy()
-> TypeError: missing required argument 'supported_checks'
This reproduces the exact class of late TypeError that PRSC-001 is meant to eliminate. Merely validating the public signature of validation_policy() cannot prove that the default-dependent call made inside its current implementation is executable.
Required correction
Add a separate call-form inventory row:
| Service method | Existing production consumer | Required accepted bound call |
|---|---|---|
| policy evidence | DescriptorPolicyProvider.validation_policy() delegation |
evidence_policy() |
Also add a hostile composition test in which supported_checks is made required. Both provider-loaded and explicitly injected paths must reject the graph with ProfileRuntimeError before transaction entry.
Update the PRSC-001 negative-case and traceability rows so a required supported_checks parameter is explicitly covered.
This correction changes only the Phase A RFC; it does not require expanding the Phase B file boundary.
Previous findings now closed
Registry-reverification result semantics — closed
The revised contract permits exactly None | GateRefusal, validates the result before truthiness or branching, and explicitly rejects empty and non-empty mappings, arbitrary falsey/truthy objects, and GatePass. It also requires rollback and absence of VALIDATION/PASS or promotion effects.
Registry-reverification profile binding — closed
The service now gains an exact active_profile binding, the common validator checks it against the Store-bound descriptor, and the negative cases include substituting a registry service from another profile. The Phase B boundary now permits the necessary narrow changes to kernel/validators.py and the SI provider constructor.
Explicit-injection source provenance — closed
The contract now distinguishes graph-coherence validation from source provenance. Production injection is described as the internal handoff of the exact graph already returned by load_profile_runtime_services(...); arbitrary direct construction and injection remain test-only.
Python metadata — closed
The repository pin is now correctly recorded as Python 3.12.13. The separate 3.14.5 observation is explicitly unsupported and non-authoritative, and the unrelated machine-specific virtual-environment path has been removed.
Non-blocking editorial correction
PRSC-001 currently says:
Every callable in the inventoried inventory
Use “every callable in the call-form inventory” or equivalent.
Authority impact
Active baseline files affected: none.
Change category: implementation/conformance RFC correction.
Smallest controlled patch: amend only the Phase A RFC to add the missing zero-argument policy call form, its hostile test requirement, and the minor wording correction.
Final result: the revised contract is materially stronger, but Phase A is not yet ready for approval at c47639972fc26a8bad72a212aafb5c0fb706f710.
PR #362 — independent Phase A pass at the same headReviewed exact head: Base / merge-base with Independent extraction of the RFC, from a fresh anonymous clone: Digest, byte count and single-file boundary match the PR body exactly. Two reviews already stand: 3 Blockers at Both prior reviews are self-reviews — Disposition: 2 Blockers (1 new, 1 independently reproduced), 1 Should fix, 1 Follow-up. Do not approve this contract or begin Phase B from this head. What I verified before forming an opinionThe three base-commit defects the RFC claims, reproduced§1 asserts three reproductions "without editing runtime code". I ran all three against the real gates and the repository's own synthetic fixture ( All three hold exactly as written. The I also ran the fourth case the 07:18Z review raised, since the RFC now closes it:
The call-form inventory (§6.2) is executable and correctly calibratedThis is the load-bearing table, so I built it as executable data and ran it both ways. Against the real SI implementations ( Against the current synthetic fixture: Exactly the two defects §1 names, and nothing else. The inventory is neither too strict (it does not break SI) nor too loose (it catches both known gaps). That is the right calibration and it is worth recording, because it is the part of this contract most likely to be wrong. The RFC's own numbersThe two package-check failures are Evidence the RFC reports as unavailable — I closed both§13.1 reports manifest verification "unavailable ... because
13 + 22 = 35, so the whole focused base suite is green, not merely its pure subset. Caveat, stated at the point of the result: my server is PostgreSQL 16.13, and the repository pins 17.10. Nothing these two modules exercise is version-sensitive as far as I can tell, but I cannot prove that, and this is not the pinned interpreter either (3.12.3, not 3.12.13). Treat it as a strong indication that the Phase B starting line is green, not as the pinned-environment evidence §13.1 asks for. Blocker 1 (new) — the approved design cannot be implemented inside the budgets this contract declares and forbids relaxing§10 says Phase B "must refactor compactly within that existing group budget; it must not add a framework module or relax the budget". §11 says "No change to architecture budgets is expected or authorized by this contract." §15 stop condition 10 makes "architecture-budget relaxation" a stop. So the budgets are a hard constraint of the thing being approved. Measured at the base commit:
(The third row matches §9.1 alone overruns the services module. I wrote the minimum idiomatic patch that satisfies §9.1 — Compressed below the module's current style (one-line functional The group overruns too. I then wrote a minimum table-driven implementation of §9.2's new obligation — the 14 inventoried call forms as data, the independent The RFC's only named offset pays nothing. §10 says "Deletable duplication is the partial type/descriptor validation branch in The test module is the tightest of the three. §13 requires Counter-argument, stated because I want this refuted with numbers if it is wrong. My 42-line validator is one encoding, not a proof of the minimum. A denser encoding — a string DSL, or packing several call forms per physical line — could squeeze under 900. But that is exactly the kind of compression §10 warns against in the other direction, and it does not help the test module at all, where 31 lines cannot hold the enumerated hostile programme under any encoding. The RFC is also honest here: §10 already says "If the approved design cannot fit after deleting the duplicate validation branch, implementation stops for an amendment." My objection is not that the RFC hides this. It is that the arithmetic is already determined at the base commit, so approving this contract would authorize a Phase B that must halt at its first architecture check — and the approval §14 requests is specifically for "the bounded Phase B implementation". Required correction (Phase A only, no code): state the budget arithmetic in §10 with these numbers, and then either (a) name the exact in-group deletions that pay for the additions — noting that Blocker 2 (independently reproduced) — the closed inventory still omits |
Independent exact-head Phase A review requestedPlease review only exact head Contract identity: RFC identity: This revision addresses both blockers reported at
The Phase B boundary now names The non-blocking findings are also incorporated:
Phase A still changes exactly one path: Verification at this head:
The earlier reviews were posted by the PR-author account. Please provide an |
PR #362 — focused exact-head re-reviewReviewed exact head: Previously reviewed head: Independent extraction: Matches the PR body exactly. One changed file; Disposition: 0 Blockers, 2 Should fix, 2 Preferences. Both Blockers from my previous pass are closed, and I verified each closure rather than reading it. The two Should-fixes below are new and both arise from the fixes themselves — one is arithmetic inside the new ceiling table, the other is a way the new extraction criterion can halt correct work. Neither admits a bad implementation; both would stop a good one. Blocker 1 — architecture budgets — CLOSED§10 now replaces the "refactor compactly within the existing budget" language with a measured ceiling table and adds I checked the obvious way this fix could still be incomplete: does anything else assert those budget constants, forcing an out-of-boundary edit?
Blocker 2 — the omitted |
| Scenario | 867 + services + provider + SI | Group total | Ceiling 950 |
|---|---|---|---|
| services 249 (compressed), readable validator | 867 + 12 + 57 + 1 | 937 | 13 spare |
| services 255 (idiomatic), readable validator | 867 + 18 + 57 + 1 | 943 | 7 spare |
| services 265 (the new ceiling), readable validator | 867 + 28 + 57 + 1 | 953 | over by 3 |
So the contract grants a service-module allowance it cannot afford to have spent. An implementer who uses the 265 lines §10 explicitly authorizes, and writes the validator in the house style rather than at my minimum, lands over the group ceiling and hits stop condition 10 — while having stayed inside every ceiling the RFC named individually.
This is much less severe than the previous head's version: 937 and 943 both fit, so a competent Phase B can land inside 950. It is no longer arithmetically guaranteed to stop. But the table as written invites the one combination that does not fit.
Required correction (Phase A only): either state in §10 that the 950 figure assumes the service module lands near 255 and that the 265 ceiling is headroom for iteration rather than budget to spend, or raise the group ceiling to about 975 so the three ceilings are independently spendable. The second is cleaner and costs one integer.
Counter-argument, stated because this is my own number being used against me: §10 already calls these "maximum guardrails, not growth targets" and requires Phase B to "report final counts", and exceeding a ceiling is an explicit stop. A reviewer could reasonably call this a Preference. I keep it at Should fix because the overlap is invisible from the table, and because a contract that authorizes 265 should not fail when 265 is used.
Should fix 2 (new) — stop condition 12 can fire on correct Phase B work
The new criterion pins the extraction failure set to exactly three paths and makes "any added path, removed path, changed diagnostic category, or inability to reproduce the base set" a stop condition. I went looking for what actually puts each path in that set. The seed terms are KMG-MID, GERK, REGSR, FFSNaprave, Slovenia, Slovenian, \bSI\b, Dutch GO, GLMC 7,Gecombineerde Opgave, scanned over roots including kernel and conformance. Measured:
kernel/tests/_synthetic_profile_runtime.py {'SI': 1} <- a baseline FAILURE
kernel/tests/test_profile_runtime_services.py {'REGSR': 5} <- covered, does not fail
conformance/rewrite_architecture_check.py {'SI': 7} <- covered, does not fail
The single \bSI\b match that makes the synthetic fixture one of the three baseline failures is its line-1 module docstring:
"""Synthetic non-SI services used only to prove the neutral runtime seam."""
That hyphenated "non-SI" is the file's only seed hit. §9.4 requires Phase B to rewrite this fixture substantially — new return shapes, the four invalidation keywords, a descriptor-bound registry service, test-only observation of the invalidation call. Updating a module docstring whose contract just changed is the natural thing to do, and it is arguably required for honesty. The moment that phrase is reworded without the token, the file stops being a seed-scan hit, the failure set drops from three paths to two, and §13.2's "removed path ... is a stop condition" halts an implementation that did nothing wrong.
The asymmetry that makes this specific rather than theoretical: the review-record glob
kernel/tests/test_profile_runtime_*.py|kernel/tests/_profile_runtime_test_support.py|...
covers test_profile_runtime_services.py — which is why its five REGSR hits do not fail — but does not cover _synthetic_profile_runtime.py, because of the leading underscore. So one of the three pinned baseline members hangs on a single word in the docstring of the one file Phase B is required to rewrite, and its sibling is immune.
Required correction: make the criterion asymmetric, since only additions indicate leakage. For example: "No path outside this set may appear. A path leaving the set must be explained and shown to follow from a permitted edit; in particular kernel/tests/_synthetic_profile_runtime.py is in the set solely because of the phrase non-SI in its module docstring, and §9.4's rewrite must either retain that phrase or record its removal as an expected baseline change." Naming the dependency is the important half — an implementer who does not know it will trip over it blind.
Preferences
P1 — §13.2 does not name the inventory-regeneration command, which is the one Phase B command that needs no database
§11 now permits conformance/review_baseline_test_inventory.json "only if the exact test additions require a mechanical inventory update". They will: adding tests to kernel/tests/test_profile_runtime_*.py changes collected node IDs. But §13.2's command list does not say how to produce that update, and the surrounding text implies the full baseline, which needs PostgreSQL 17.10 and the pinned interpreter.
There is a dedicated subcommand, and it does not touch a database. Run at this head:
python conformance/run_review_baseline.py update-inventory
-> wrote conformance/review_baseline_test_inventory.json with 3861 pinned tests
-> git status --porcelain: empty (clean no-op; the committed inventory is current)
Naming that command in §13.2 makes "mechanical" verifiable rather than asserted, and it gives Phase B one required artifact it can produce in any environment.
P2 — cite the corroborating review by its comment id
§13.1's new paragraph is accurate and I withdraw the objection I was forming. I checked the PR's review objects, its issue comments and its inline review comments: the c476399 review was posted to this PR as issue comment 5539699935 at 2026-09-04T11:20:23Z under the samovers account, so "the review was posted by the PR-author account" is correct, and treating it as non-independent, non-pinned corroboration is the right disposition.
Two small things follow from where it landed. It is a PR comment, not a GitHub review object, so §14's "Both review artifacts were posted by the PR-author account" counts two review objects while §13.1 cites a third artifact of a different kind — worth one clause so the record is unambiguous. And it was pasted as inline-styled HTML rather than markdown (61,343 bytes for a 21,753-byte source), which renders poorly on GitHub. Cite the comment id in §13.1, and consider re-posting the body as markdown.
Re-verified at this head
Everything below was re-run at 646d24e, not carried over. The RFC is documentation-only, so the code results are identical to the previous head by construction; I ran them anyway because that is cheaper than assuming it.
git diff --name-only 0c55f5c...646d24e -> 1 file (the RFC)
git diff --check -> clean
git status --short -> clean
ofarm_profile_extraction_consistency_check.py -> FAIL (3 failures), the same three paths
ofarm_pkg_contract_check.py -> RESULT: FAIL (2 failures) [environmental]
run_review_baseline.py update-inventory -> no-op, 3861 pinned tests, worktree clean
kernel.manifest --verify-generated -> RESULT: PASS
pytest test_profile_runtime_services.py test_profile_runtime_neutrality.py -q
-> 35 passed in 13.02s
The two package-check failures remain UNSUPPORTED_PYTHON_VERSION from temporal_contract_candidate_check and rewrite_architecture_check, identical at base and head. The manifest and focused-suite results carry the same caveat as before and as §13.1 now records: PostgreSQL 16.13 against a pinned 17.10, CPython 3.12.3 against a pinned 3.12.13. They corroborate; they are not pinned-environment acceptance evidence.
Checked and decided were not findings
- Does the ceiling change force an edit outside the boundary? No —
kernel/tests/test_rewrite_architecture_check.pydoes not assert the budget constants, andconformance/rewrite_architecture_check.pyis not digest-pinned in any manifest or the RuntimeBundle. This was the most likely way the budget fix could have been incomplete. - Does editing the architecture checker perturb the extraction baseline? No. It already carries seven
\bSI\bhits and is already covered by a review record; changing three integers adds no seed term. - Will the regenerated inventory perturb the extraction baseline? No. It is already a hit path (one
\bSI\b, inside atest_rewrite_architecture_check.pynode ID) and already a baseline failure; adding node IDs keeps it in the set. - Is the 1,100-line test ceiling enough? 331 lines beyond the base for roughly 45 enumerated hostile cases. Feasible with
pytest.mark.parametrize, which the module already uses. Tight but not a finding. - Is the new
evidence_policy()row consistent with §6.2's stated inclusion rule? Yes, and it removes the inconsistency I noted last time: the inventory now includes both intra-implementation delegations (recomputefromresolve_for_use,evidence_policyfromvalidation_policy) rather than one of the two. - Does the revision alter any invariant, non-effect, trust-model or authority-map row beyond the findings? No. The diff is confined to §1, §6.2, §7, §8, §9.2, §10, §11, §13, §14 and §15, and every change traces to a prior finding.
Could not be checked, and why
- The pinned environment, again: CPython 3.12.13 is not obtainable here (
uv python install 3.12.13→ "No download found for request: cpython-3.12.13-linux-x86_64-gnu") and PostgreSQL 17.10 is blocked by the egress gateway. §13.1's "PASS under Python 3.12.13" claims for the package and architecture checks remain unconfirmed by me. - The complete Kernel suite and the two-run review baseline: Phase B evidence, and both need the pinned PostgreSQL.
- Phase B itself does not exist. Should fix 1 is again a claim about code that has not been written; it rests on measured line counts of two encodings I wrote, not on a prediction of the author's.
What my method made easier than production
- My own prior numbers are now inside the contract, and one of them was a floor. §10's 931 figure is my minimal-encoding measurement, which I labelled "a lower bound on my own encoding, not a proof of the minimum". The RFC has treated it as the design size. Should fix 1 exists because I wrote a second, more realistic encoding and it is 12 lines larger. A third implementer will get a third number; none of the three is authoritative, and the contract should not read as if one is.
- The live results are PostgreSQL 16.13 and CPython 3.12.3, both off-pin.
- The seed-scan analysis applied the term patterns from
conformance/ofarm_profile_extraction_consistency_check.pydirectly to file text rather than invoking the checker's own scanner, so it reproduces which files contain the terms, not the checker's full hit/coverage resolution. The three-path failure set I compared against came from running the real checker; the per-file term counts behind Should fix 2 came from my own regexes.
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #362 — exact-head Phase A re-review
Reviewed exact head:
646d24e7c4c46061b60369fc6771271208301468
against base:
0c55f5cc6665ffef4c57591dafe014ad9bc44524
The PR remains draft and documentation-only, with one changed file. Lightweight CI passed at this exact head.
Disposition
2 Blockers.
The previous missing evidence_policy() call-form and architecture-budget findings are closed. However, the proposed “complete graph” check still permits a graph owned by the wrong Store or split across two context assemblers, and the new registry-result rule treats any nominal GateRefusal as trustworthy without proving that it is a valid, logged refusal.
Phase B should not begin from this head.
Blocker 1 — PRSC-003 binds the descriptor, but not the Store or the materializer’s actual context service
Violated invariant
PRSC-003 claims one coherent graph, and the trust model identifies a tenant-bound Store, service attributes, and materializer bindings as part of the trust boundary. Yet the required validation order checks the Store’s descriptor, specifications, service descriptors, and output materializer identity—not the Store that owns each executable service, nor the context assembler actually retained by the materializer.
The proposed validator can therefore remain structurally equivalent to the current:
_validate_services(services, descriptor)which has no expected-Store argument. Its existing cross-bindings include output assembler → materializer, but not materializer → context assembler or service → Store.
Production-reachable counterexample
Assume two startup-complete tenant-bound Stores share the same immutable profile descriptor object:
store_a
store_b
descriptor = store_a.active_descriptor = store_b.active_descriptorAn admitted registered factory called for store_a can accidentally return a coherent graph constructed for store_b:
def admitted_factory(_store_a, descriptor):
return build_services(store_b, descriptor)That graph satisfies every stated check:
- exact
ProfileRuntimeServicestype; - exact descriptor object;
- correct service
descriptor/active_profileidentities; - exact materialization and output specification bindings;
- exact output assembler → materializer binding;
- compatible signatures.
But the concrete services retain their own Store. ContextAssembler stores self.store; Materializer stores both self.store and self.context; and SIOutputAssembler stores its Store, constructs authority against it, and later opens transactions through it.
The materializer then combines its retained context and Store with the cursor supplied by the calling pipeline:
ctx = self.context.assemble(cur, ...)
consequences = self.store.in_force_consequences(...)The result is a pipeline composed for Store A that may read, authorize, lock, materialize, or receipt against Store B. Store receipts explicitly derive tenant and RuntimeBundle identity from the retained Store, not from the supplied cursor.
There is also a simpler split-context graph:
bad = replace(
services,
context_assembler=another_assembler_with_the_same_descriptor,
)The proposed validator accepts it, while:
ProfileApplicabilityGateusesbad.context_assembler;bad.materializercontinues using its separately retainedmaterializer.context.
Applicability and materialization can therefore be based on different context services despite PRSC-003 claiming one coherent graph.
Required correction
The common validator must receive the exact composition Store—or an assertion-equivalent exact tenant/RuntimeBundle owner token—not only its descriptor.
At minimum, the contract should require:
context_assembler.store is expected_store
materializer.store is expected_store
output_assembler.store is expected_store
materializer.context is context_assembler
Registry reverification also needs an exact Store/runtime-owner provenance binding, because its product lookup is populated from Store-selected reference data; active_profile alone does not prove that the lookup came from the selected Store.
Add hostile tests for both composition paths:
- a fully coherent service graph constructed for a second Store using the same exact descriptor;
- a bundle context assembler different from
materializer.context.
Both must fail during composition, before any transaction starts.
These additions fit the existing Phase B file boundary. The measured 265/950 ceilings appear to leave enough room, but the amended RFC should include these checks in PRSC-003, its negative cases, and its verification table.
Blocker 2 — nominal GateRefusal type does not prove a lawful or logged refusal
Violated invariant
The RFC now validates the registry result as:
None | GateRefusal
and says any GateRefusal follows the governed-refusal path. It does not validate the refusal’s fields or prove that the provider logged the decision.
GateRefusal itself is only a mutable data container:
@dataclass
class GateRefusal:
gate: str
outcome: str
final_outcome: str
problems: list[dict]It enforces no gate identity, final-outcome restriction, problem shape, or logging side effect.
The existing Kernel refusal helper deliberately logs before constructing the result because every refusal must appear in both the gate log and PromotionTrace:
ctx.log("VALIDATION", outcome, ...)
return GateRefusal("VALIDATION", outcome, final, [problem])Production-reachable counterexample
An admitted registry-reverification service can return an otherwise plausible refusal without logging:
def run(self, context):
return GateRefusal(
gate="VALIDATION",
outcome="FAIL_REGISTRY",
final_outcome="RETAIN_DRAFT",
problems=[valid_runtime_problem],
)The proposed runtime check accepts it because it is a GateRefusal.
GatePipeline then:
ctx.problems.extend(outcome.problems)
ctx.final_outcome = outcome.final_outcome
return PromotionTraceWriter().write(ctx)It does not validate gate, outcome, final_outcome, or whether a matching gate entry exists.
PromotionTraceWriter persists the existing ctx.gate_sequence and the provider-selected final outcome. Because the provider never called ctx.log, the durable trace can end in RETAIN_DRAFT without any VALIDATION entry explaining the refusal.
Other malformed-but-nominal cases also pass the proposed type check:
gatenames another gate;outcomedoes not match the logged outcome;final_outcomeis not a lawful validation disposition;problemsis empty or malformed;- the provider logs one result but returns another.
This is a durable silent governance outcome, not merely an exception-shape problem.
Required correction
Do not treat isinstance(result, GateRefusal) as sufficient evidence.
The contract must choose one of these controlled designs:
- ValidationGate owns normalization and logging. The provider returns a narrow private refusal payload, and the generic gate constructs and logs the actual
GateRefusal; or - ValidationGate validates an already-logged refusal. Before returning it, require at least:
- the exact
VALIDATIONgate identity; - an explicitly enumerated lawful validation final outcome;
- non-empty, contract-valid
RuntimeProblemvalues; - a matching
VALIDATIONgate-log/gate_sequenceentry produced by that invocation; - agreement between the logged and returned outcomes.
- the exact
Any malformed or unlogged GateRefusal must raise ProfileRuntimeError and roll back.
Required tests:
unlogged otherwise-valid GateRefusal
wrong gate
unlawful final_outcome
empty or malformed problems
logged outcome differing from returned outcome
one correctly logged and well-formed refusal
The first five must fail as implementation-contract violations. The final case must produce exactly one governed validation refusal.
Previous findings now closed
The zero-argument policy call is now independently admitted alongside evidence_policy(supported_checks=...), and the negative-case table covers a provider that makes supported_checks required.
The architecture arithmetic is now explicit rather than deferred: the RFC authorizes only the measured 950-line group ceiling, 265-line service-contract ceiling, and 1,100-line focused test-module ceiling.
The revised Phase B boundary now explicitly permits only those architecture-checker constants, and the extraction failure posture is bounded rather than represented as green.
The earlier registry non-type-result cases, registry descriptor binding, explicit-injection provenance clarification, Python-version metadata, and wording correction remain closed.
Authority impact
Active baseline files affected: none.
Change category: implementation/conformance RFC correction.
Smallest controlled patch: amend only the Phase A RFC to add the missing Store/context graph bindings and complete GateRefusal semantics, tests, and traceability mappings. No runtime implementation should begin until that new exact head receives another zero-blocker review and explicit task-user approval.
Final result: Phase A is not ready for approval at 646d24e7c4c46061b60369fc6771271208301468.
Bind the executable graph to its exact Store and context owner, place registry-refusal normalization and logging under ValidationGate, and make the architecture and extraction acceptance rules internally usable. This remains documentation-only Phase A for issue #160.
Independent exact-head Phase A review requestedPlease review only exact head Durable contract: Expected independent extraction: This remains a draft, documentation-only Phase A head with one changed file. Please classify findings as Blocker, Should fix, Preference, or Follow-up and
Please also verify that the 975 group ceiling is jointly usable with the 265 The primary trust boundary remains runtime integration and readiness at the Prior reviews and comments were posted by the PR-author account and do not |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #362 — focused exact-head Phase A re-review
Reviewed exact head:
8848d089de01b941cd1f30272ecd5bb624724e70
against base:
0c55f5cc6665ffef4c57591dafe014ad9bc44524
The PR remains a draft, documentation-only Phase A change with one changed file. The current head contains five commits and 1,051 added lines.
Disposition
2 Blockers.
The two findings from the previous review are addressed at their stated level:
- the common validator is now Store-aware and checks
materializer.context; - provider-created
GateRefusalvalues are replaced by a narrow private envelope whose refusal semantics are owned byValidationGate.
However, the replacement still leaves provider-controlled mutation channels outside the result contract, and the new Store checks bind owner attributes without binding the actual policy and registry data that drive decisions.
Phase B should not begin from this head.
Blocker 1 — PRSC-007 validates the return value but not the provider’s complete mutation surface
Violated invariant
PRSC-007 says only ValidationGate owns registry-refusal logging and that no provider-authored or mismatched log may commit. The proposed mechanism snapshots only ctx.gate_sequence, permits either no delta or one REGISTRY_REVERIFIED entry for a None result, and permits no such delta for a refusal.
That is insufficient because the provider receives the full mutable GateContext, including:
ctx.cur
ctx.store
ctx.gate_sequence
ctx.review_route_reasonsGateContext.log() normally updates two independent carriers: it appends to gate_sequence and separately calls Store.log_gate(). Store.log_gate() is also directly callable and inserts a durable kernel_gate_log row without touching the in-memory sequence.
Production-reachable counterexample 1 — durable-log-only write
An admitted registry service can do:
def run(self, ctx):
ctx.store.log_gate(
ctx.cur,
ctx.request_id,
"VALIDATION",
"PROVIDER_AUTHORED_RESULT",
)
return NoneThe proposed check sees an unchanged gate_sequence, which is explicitly allowed for None. The transaction can therefore commit:
- a provider-authored durable gate row in
kernel_gate_log; - no corresponding entry in the PromotionTrace’s
gateSequence; and - the later generic
VALIDATION/PASSentry.
The opposite divergence is also admitted:
def run(self, ctx):
ctx.gate_sequence.append({
"gate": "VALIDATION",
"outcome": "REGISTRY_REVERIFIED",
})
return NoneThis exactly matches the permitted in-memory success delta, but no durable gate-log row exists. In both cases, one carrier says something the other does not.
Production-reachable counterexample 2 — malformed hidden review result
Registry reverification currently communicates a review outcome by mutating ctx.review_route_reasons and returning None. It also optionally writes REGISTRY_REVERIFIED through ctx.log().
The revised contract explicitly preserves those review-routing effects, but does not validate their delta or shape. A provider can therefore do:
def run(self, ctx):
ctx.review_route_reasons.append({})
return NoneThis has an allowed result and no gate-sequence change. Later, ReviewPromotionGate treats every list member as a valid RuntimeProblem and directly indexes the first item’s reasonCode. The malformed provider effect consequently fails late with KeyError, rather than the promised ProfileRuntimeError.
Material consequence
The current contract still admits:
- durable gate-log and PromotionTrace disagreement;
- provider-authored durable logging despite generic ownership;
- malformed hidden review results reaching later stages; and
- an incidental late
KeyErrorafter registry validation ostensibly succeeded.
That directly contradicts PRSC-007’s stated containment.
Required correction
The clean design is to make registry reverification return one closed private outcome covering all three legitimate states:
REVERIFIED
REVIEW_REQUIRED(problem)
REFUSED(problem)
The provider should not mutate gate_sequence, call either logging path, or append directly to review_route_reasons. ValidationGate should validate the outcome and exclusively perform the corresponding success log, review-route append, or governed refusal.
If the side-effect model is retained, the contract must instead define and validate all allowed deltas:
- the exact transaction-local
kernel_gate_logrows; - the matching
gate_sequenceentries; - the exact
review_route_reasonsprefix and additions; and - the shape and registered reason code of every added RuntimeProblem.
Required hostile tests must cover:
durable log only
gate_sequence entry only
log then remove the in-memory entry
malformed review-route value
mutation of an existing review-route prefix
one valid reverified result
one valid review-required result
one valid fixed refusal
The first five must raise ProfileRuntimeError and leave no durable effect.
Blocker 2 — PRSC-003 binds Store markers, not the runtime-selected data actually used
Violated invariant
The revised common validator requires exact Store identity for context, materializer, registry-reverification, and output services. It does not require the policy service to be bound to the exact Store or RuntimeBundle policy component; policy admission remains only a matching policy_ref and recognized-rule set.
The authority map similarly defines policy identity only through the descriptor’s evidence-policy ref and required rule refs. For registry reverification, it checks the service’s .store marker but does not bind the detached lookup data that the service actually consults.
Production-reachable counterexample 1 — path-backed or foreign policy content
DescriptorPolicyProvider has two materially different construction modes:
DescriptorPolicyProvider(descriptor)loads policy later from the descriptor’s filesystem path, while:
DescriptorPolicyProvider.from_runtime_bundle(
descriptor,
canonical_policy_bytes,
...
)retains the selected RuntimeBundle policy document. Both modes expose the same:
descriptor
policy_ref
recognized_rule_refs
method signatures
and the current provider object exposes no Store, RuntimeBundle, component, or content-digest binding.
An admitted factory called for Store A can therefore return an otherwise coherent Store-A graph with:
policy_provider = DescriptorPolicyProvider(descriptor)or with a provider built from foreign/stale policy bytes carrying the same policyId.
That graph passes every stated PRSC-003 check. At runtime, validation and evidence sufficiency can use filesystem or foreign policy content while materialization and receipts identify Store A’s RuntimeBundle.
This is not hypothetical API misuse: the active SI factory must explicitly fetch the Store-selected PROFILE_POLICY component and pass its canonical bytes to avoid exactly that fallback.
Production-reachable counterexample 2 — foreign lookup behind a correct Store marker
SIProductRegister.load_from_store() copies exact Store-selected reference-source data into a detached _by_snapshot lookup. After loading, the lookup retains bindings and copied data, but no Store or RuntimeBundle owner.
The registry validator separately retains that lookup and uses it for the actual identity decision:
confirmed = self.product_lookup.lookup_by_decision(
current_id,
decision_number,
)After the proposed Phase B constructor change, this still composes:
lookup_b = product_lookup_loaded_from(store_b)
registry = RegistryReverificationValidator(
store=store_a,
active_profile=shared_descriptor,
snapshot_prefix=store_a_prefix,
product_lookup=lookup_b,
)The common validator sees .store is store_a and the correct descriptor, so it accepts the graph. During execution, current snapshot selection comes from Store A while identity confirmation comes from Store B’s detached lookup data.
The RFC itself acknowledges this gap by leaving construction of the lookup from the correct Store to the admitted factory rather than proving it at graph admission.
Material consequence
A graph can make policy, evidence-floor, reference-identity, or review-routing decisions from bytes not selected by the RuntimeBundle named in its receipts. That breaks determinism and makes the RuntimeBundle digest an inaccurate account of what governed the result.
Required correction
The common composition contract must bind actual selected inputs, not merely owner labels.
For policy, require the policy service to retain an immutable binding to the exact Store-selected PROFILE_POLICY component—such as its exact canonical bytes, exact component object, or content digest—and compare that binding against:
expected_store.runtime_bundle.component(
RuntimeComponentRole.PROFILE_POLICY,
descriptor.evidence_policy_ref,
)A descriptor-path compatibility provider and a provider carrying different policy bytes under the same ref must be rejected.
For registry reverification, require the actual lookup to retain verifiable provenance from the exact expected Store or RuntimeBundle. Acceptable minimal approaches include:
SIProductRegisterretaining the exact source Store/RuntimeBundle identity when loaded;- retaining and checking the selected reference-source component digests actually represented in the lookup; or
- constructing the lookup inside a Store-bound service so no independently cross-wirable lookup remains.
Required tests for both provider-loaded and injected paths:
descriptor-path policy provider
foreign policy bytes with the same policy ref
registry.store = Store A with lookup data from Store B
wrong snapshot-prefix binding with otherwise correct Store and descriptor
All must fail at composition.
The current Phase B boundary excludes both kernel/profile_policy.py and kernel/context.py. If the controlled implementation needs either file to expose these immutable bindings, the RFC boundary and architecture arithmetic must be amended before Phase B.
Previous findings now closed
The revised contract correctly adds the expected Store to the common validator, requires the four Store-owning top-level services to retain it, and requires materializer.context to be the exact bundle context assembler.
The provider can no longer return a nominal GateRefusal with provider-selected gate, outcome, final outcome, or problem-list cardinality. The exact private envelope and generic fixed refusal are the right direction.
The earlier zero-argument policy-call admission, measured architecture ceilings, descriptor naming clarification, and asymmetric extraction-baseline rule remain addressed.
Authority impact
Active baseline files affected: none.
Change category: implementation/conformance RFC correction.
Smallest controlled next patch: amend the Phase A RFC so registry reverification has one complete explicit outcome/mutation contract and so policy/reference decisions are tied to the exact RuntimeBundle inputs they use. Update the Phase B file boundary only where those bindings genuinely require it.
Final result: Phase A is not ready for approval at 8848d089de01b941cd1f30272ecd5bb624724e70.
Revised exact-head Phase A review requestedPlease review only exact head Contract identity: RFC identity: Phase A still changes exactly one path: This revision addresses both Blockers in formal review #5113776610:
The Phase B boundary now narrowly permits Conditional architecture ceilings and PR-local caps are explicit and jointly Verification on this exact content:
Please first state whether each prior Blocker is cleared. Classify any new Phase B must not begin until this exact head has a zero-Blocker independent |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #362 — exact-head Phase A re-review
Reviewed exact head:
e23872030e02d119a5695cb6c49cdd52d730847e
against base:
0c55f5cc6665ffef4c57591dafe014ad9bc44524
The PR remains draft and documentation-only, with one changed file and six commits. The lightweight workflow passed at this exact head.
Disposition
2 Blockers.
The previous two blockers are substantially closed at their stated level:
- registry reverification no longer receives the mutable
GateContext; and - policy and lookup objects now carry exact RuntimeBundle provenance.
However, the mutation fix has made the common Kernel contract explicitly product-register-shaped, contrary to the ticket’s profile-neutrality requirement. Separately, the proposed provenance check still does not establish which of several descriptor reference families is authoritative for this capability.
Phase B should not begin from this head.
Blocker 1 — the common service contract now requires an SI-style product decision register
Violated boundary
Issue #160 explicitly says:
Do not make every future provider implement an imaginary universal product
register. Registry reverification remains a capability-specific service
supplied by the provider.
The revised RFC does the opposite in three connected places:
-
kernel/profile_runtime_services.pygains a commonProfileRegistryLookupprotocol requiring:lookup_by_decision(snapshot_id, decision_number)
-
Every registry service must retain a
product_lookup, snapshot prefix, RuntimeBundle and selected-source tuple. -
Generic
ValidationGatenow resolves a verifiedCROP_PROTECTION_PRODUCTbinding, extracts itsregistrationRefas adecision_number, determines whether a product-register snapshot advanced, and skips the provider service when those product-specific preconditions are absent.
This is not merely private plumbing. It moves the SI D9 product-identity model—decision-number lookup over a crop-protection-product registry—into the mandatory common graph and generic gate.
The RFC also contradicts itself: it introduces the new ProfileRegistryLookup protocol and then says that no new service abstraction is needed.
Production-reachable counterexample
Consider a legitimate non-SI provider that needs to reverify:
farm/holding registration status
organic certificate status
control-body authority and certificate validity
It has no CROP_PROTECTION_PRODUCT binding, no product decision-number index and no reason to implement lookup_by_decision(snapshot_id, decision_number).
Under the proposed contract:
- without a fabricated
product_lookup, its graph fails common composition; - with a decorative lookup added merely to satisfy the protocol,
ValidationGatefinds no verified crop-protection-product binding and takes the code-ownedNO CALL -> NO EFFECTbranch; - consequently, the profile’s genuine holding or certificate reverification service cannot execute through this boundary.
This is directly relevant to the planned Serbian runtime. Issue #161 says that the Serbian descriptor must use only genuinely applicable reference families and must not fabricate decorative empty reference or code-binding structures merely to satisfy SI-era shapes.
The synthetic non-SI fixture is already being forced in the same direction: the RFC now requires it to invent synthetic selected reference-source components and a product lookup even though its existing registry service is a simple no-op and the ticket requires it primarily to prove generic applicability and materialization.
Material consequence
PRSC-008’s profile-neutrality claim is false. A future provider must either:
- model an unrelated registry as a crop-protection product decision register;
- add decorative data and methods that have no domain meaning;
- accept that its registry verifier is never called; or
- fork or expand the Kernel.
That is exactly the architecture OFARM’s profile boundary is intended to avoid.
Required correction
Keep only the effect handling generic:
validate exact result
apply no effect / success log / review reason / fixed refusal
Do not make product-register applicability or lookup a common Kernel concern.
The smallest controlled redesign is:
- remove
ProfileRegistryLookupandlookup_by_decision(...)from the common service contract; - keep any product lookup private inside the SI registry-reverification implementation;
- do not have generic
ValidationGateextractregistrationRefor decide whether a product-register snapshot advanced; - pass the provider a frozen, profile-neutral request containing immutable generic inputs, such as canonical claim bytes, normalized event time and selected reference-snapshot metadata;
- add an exact
NO_EFFECTorNOT_APPLICABLEoutcome so the profile service—not the Kernel—decides whether its capability applies; - expose generic immutable selected-input provenance on the registry service itself, without exposing a universal product-lookup API.
Add a hostile neutrality case in which a provider with no product registry composes and returns a lawful no-effect or certificate-style classification without fabricating CROP_PROTECTION_PRODUCT, decision_number, or lookup_by_decision.
Blocker 2 — “one descriptor family” does not identify the registry family for this capability
Violated invariants
PRSC-003 claims one coherent provenance-bound graph. The proposed validator requires:
registry prefix == lookup prefix
registry prefix is one descriptor reference-family prefix
selected-source tuple matches Store selection for that prefix
It does not identify which descriptor family owns product registry reverification.
The active SI descriptor contains three unrelated reference families:
referencesnapshot:si.uvhvvr.ffs-reg
referencesnapshot:si.mkgp.gerk-layer
referencesnapshot:si.uvhvvr.ffs-naprave
Only the first is the crop-protection product register.
Production-reachable counterexample
A provider can return an otherwise exact graph with a lookup honestly loaded from the expected Store’s GERK selection:
lookup.runtime_bundle = store.runtime_bundle
lookup.snapshot_prefix = "referencesnapshot:si.mkgp.gerk-layer"
lookup.selected_source_bindings = tuple(
identities_from(
store.selected_reference_source_data(
"referencesnapshot:si.mkgp.gerk-layer"
)
)
)
registry.active_profile = descriptor
registry.snapshot_prefix = lookup.snapshot_prefix
registry.product_lookup = lookupThis satisfies every stated composition check:
- exact RuntimeBundle;
- exact descriptor;
- prefix equality;
- prefix present in
descriptor.reference_families; - truthful selected-source identity tuple;
- compatible lookup and service signatures.
An operation’s product binding can still carry:
capturedAgainstSnapshotRef =
referencesnapshot:si.uvhvvr.ffs-reg.<version>
The detached request constructor requires only that current_snapshot_ref and captured_against_snapshot_ref are non-empty and different. It does not require them to belong to the same admitted family.
The generic gate can therefore compare a current GERK snapshot with a captured REGSR snapshot and ask the product classifier to resolve a decision number against GERK-derived data. Depending on the lookup implementation, the result may be a false review, a false REVERIFIED, or an exception normalized only after entering the transaction.
The ffs-naprave family exposes the inverse problem: because it is descriptor-declared but has no shipped snapshot in the descriptor, selecting that truthful family can cause the generic no-current-snapshot branch to skip product reverification entirely.
Material consequence
Exact provenance is being proved for the wrong source family. RuntimeBundle identity and source digests do not help when the selected family itself is semantically unrelated to the decision.
That violates PRSC-003 and can break PRSC-009’s unchanged SI decision equivalence.
Required correction
The contract must name the authority that selects the exact reference family for each registry-reverification capability. Membership in descriptor.reference_families is insufficient.
At minimum:
- the SI registry service must be bound to the exact REGSR
ReferenceFamily, not any family in the descriptor; - the captured-against and current snapshot refs must both be proven to belong to that same family before classification;
- a GERK or FFSNaprave service/lookup pair with otherwise truthful provenance must be rejected;
- both provider-loaded and injected hostile tests must cover this same-descriptor, wrong-family graph.
Once Blocker 1 is corrected, this binding should remain profile-owned. The common Kernel may verify an explicit immutable capability/family binding, but it should not encode si.uvhvvr.ffs-reg or infer product semantics from arbitrary descriptor membership.
Previous findings now closed
Mutable registry effects — closed
The provider receives an exact frozen scalar request rather than GateContext, cursor, Store or mutable review/log containers. ValidationGate owns the correlated success, review and refusal effects, and provider exceptions or malformed outcomes become ProfileRuntimeError.
Policy provenance — closed for the stated trusted-source model
The runtime policy constructor retains the exact selected frozen PROFILE_POLICY component, and composition compares it by identity with the component in the expected Store’s RuntimeBundle. Path-backed and equal-but-distinct components are excluded.
Lookup source provenance — closed at the byte-selection level
The lookup retains the expected RuntimeBundle and an ordered tuple of selected snapshot, artifact and source-digest identities derived from the same rows used to populate it. The remaining problem is capability/family selection, not Store-B provenance.
The earlier call-form, minimum result shape, Store/context binding, generic result validation, architecture-budget and asymmetric extraction findings remain addressed.
Authority impact
Active baseline files affected: none.
Change category: implementation/conformance RFC correction.
Smallest controlled patch: amend the Phase A RFC so the common boundary remains registry-capability-neutral, and explicitly bind the current SI registry service to its exact REGSR family. No runtime implementation should begin before the corrected exact head receives another zero-Blocker review and explicit task-user approval.
Final result: Phase A is not ready for approval at e23872030e02d119a5695cb6c49cdd52d730847e.
Revised exact-head Phase A review requestedPlease review only exact head Contract identity: RFC identity: Phase A still changes exactly one path: This revision addresses both Blockers in formal review #5114622747 and audits
The prior mutation-free request/outcome, sole generic effect ownership, exact Verification on this exact content:
Please first state whether both prior Blockers are cleared. Classify any new Phase B must not begin until this exact head has a zero-Blocker Phase A review |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #362 — exact-head Phase A re-review
Reviewed exact head:
aa6956e4dd2c795c9acc0c980b5d299b2d13f030
against base:
0c55f5cc6665ffef4c57591dafe014ad9bc44524
The PR remains draft and documentation-only, with one changed file. The exact-head lightweight workflow passed.
Disposition
0 Blockers.
The Phase A contract is ready for explicit task-user approval. This clears the contract for the bounded Phase B implementation only; it does not approve implementation that has not yet been reviewed, authorize merge, or change production-readiness posture.
Previous Blocker 1 — closed
The common Kernel contract no longer requires an SI-style product register.
The revised design:
- removes the common lookup protocol and
lookup_by_decision(...)requirement; - keeps product roles, registration references, decision numbers, captured-snapshot interpretation, and product lookup inside the SI implementation;
- gives the generic gate only a detached, immutable request containing canonical claim bytes, resolved binding bytes, normalized event time, and an optional current snapshot reference;
- calls the profile service for every applicable operation-stage execution; and
- adds
NO_EFFECT, allowing a familyless or non-product registry service to execute without decorative product data.
The required evidence now includes both:
- a familyless synthetic service that executes without product bindings, lookup APIs, or reference-source decoration; and
- a certificate-style service that can produce a review result without any crop-protection-product concepts.
That is sufficient to establish the intended profile-neutral boundary without introducing a generic plugin framework or capability bag.
Previous Blocker 2 — closed
The registry capability now has an explicit and testable family authority.
The outer service bundle carries one exact optional ReferenceFamily. Common composition checks that:
- the value is either exact
Noneor the identical object from the selected descriptor; - the registry service retains that exact outer value;
- a family-bound service retains the exact expected RuntimeBundle and selected-input identity tuple; and
- a familyless service retains no RuntimeBundle provenance and an empty tuple.
The common Kernel does not decide what the family means. The admitted SI factory and SI registry constructor separately require the descriptor’s exact REGSR family. GERK, FFSNaprave, equal-but-distinct family objects, mismatched selected inputs, and cross-family service substitution are explicitly covered as hostile cases.
This correctly separates:
profile-owned semantic family selection
from:
generic graph and provenance coherence checking
Remaining contract coherence
The earlier corrections remain intact:
- both composition paths use one Store-aware validator;
- Store, context assembler, materializer, specifications, output assembler, policy component, registry family, and selected inputs are cross-bound;
- policy execution is tied to the exact RuntimeBundle-selected
PROFILE_POLICYcomponent; - registry reverification receives no cursor, Store,
GateContext, gate log, review list, or mutation callback; - only
ValidationGateappliesNO_EFFECT, success, review, or refusal effects; - applicability and materialization references are validated before their success entries; and
- malformed provider behavior raises
ProfileRuntimeErrorinside the existing rollback boundary.
The Phase B file boundary also covers the repository’s actual construction sites: the SI provider, synthetic fixture, and focused service tests are the only current ProfileRuntimeServices(...) construction locations.
The revised architecture limits are internally consistent. The explicitly capped profile-runtime modules total at most 1,030 lines under the 1,050-line group ceiling, leaving the stated 20-line guard margin without reopening unrelated module headroom.
Authority impact
Active baseline files affected: none.
Change category: implementation/conformance implication.
Review result: exact head aa6956e4dd2c795c9acc0c980b5d299b2d13f030 has zero demonstrated in-scope Blockers. Phase A is ready for the user’s explicit approval and then bounded Phase B implementation.
Route loaded and injected service graphs through one Store-bound validator, validate provider result minima before success logs, and give registry reverification a detached neutral request with code-owned outcomes. Add hostile, neutrality, SI-equivalence, and mechanical conformance evidence for issue #160.
Exact-head Phase B implementation review requestedPlease review only exact head Approved Phase A authority:
Current RFC implementation-record identity: Primary trust boundary: runtime integration and readiness at the private Please verify every PRSC invariant and first state whether the implementation
Please also audit for overdesign and drift. The common Kernel must not gain an Local supported Python 3.12.13 evidence:
The unmodified complete Kernel command is honestly non-green on this host: Classify each finding as Blocker, Follow-up, or Preference. A Blocker should This draft must not merge until this exact head has no demonstrated in-scope |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #362 — exact-head Phase B implementation review
Reviewed exact head:
2d0ccff0fd12fd9577c379b9c03120c61a72c6a7
against base:
0c55f5cc6665ffef4c57591dafe014ad9bc44524
The PR remains a draft with 15 changed files.
Disposition
Request changes: 2 Blockers.
The implementation largely and cleanly realizes the approved design. I found no renewed product-register abstraction, plugin framework, dynamic discovery, profile composition, Serbia activation, or other architectural drift. However, one malformed graph still escapes the promised error boundary, and two explicitly required SI runtime behaviors lack the contract-mapped evidence.
Do not create baseline admission for this head.
Blocker 1 — malformed policy metadata can still escape composition as raw TypeError
Violated invariant
PRSC-007 requires malformed graphs and service attributes to fail through ProfileRuntimeError, not incidental AttributeError, TypeError, or KeyError.
The common validator currently performs:
required_rules.issubset(
services.policy_provider.recognized_rule_refs
)without first validating the runtime type of recognized_rule_refs, and without an ordinary-exception normalization boundary around the candidate graph inspection.
A runtime_checkable protocol checks that an attribute exists; it does not enforce the annotation frozenset[str].
Minimal reproduction
Both the provider-loaded and injected paths can receive:
services = build_si_runtime_services(store, descriptor)
services.policy_provider.recognized_rule_refs = None
GatePipeline(store, runtime_services=services)The service still has every required attribute and callable. Call-form validation and the preceding identity checks succeed. The final issubset(None) then raises:
TypeError: 'NoneType' object is not iterable
instead of ProfileRuntimeError.
The same structural problem exists for candidate attributes implemented as raising properties. _validate_call_forms() resolves every method while constructing calls, before entering its current try block. A malformed property-backed method can therefore leak an arbitrary ordinary exception from composition.
Material consequence
A malformed provider graph can produce an ungoverned startup/composition exception outside the stable profile-runtime error contract. Callers that correctly handle ProfileRuntimeError can instead crash on an incidental implementation exception.
No transaction starts, but PRSC-007 is still false at the primary runtime-integration boundary.
Smallest correction
Keep the existing design and:
- validate
recognized_rule_refsbefore callingissubset, consistently with its declaredfrozenset[str]contract; - move candidate callable extraction inside the exception-normalization block; and
- normalize ordinary exceptions raised while inspecting candidate service attributes or signatures to
ProfileRuntimeError, while allowingBaseExceptioncontrol-flow signals to propagate.
Add one parameterized hostile case for both composition paths using malformed recognized_rule_refs, and preferably one raising callable property. Assert ProfileRuntimeError and zero transaction entry.
This is an in-boundary correction to kernel/profile_runtime_provider.py and the existing focused test module. It does not require a new abstraction or Phase A redesign.
Blocker 2 — the focused suite does not prove two required SI behaviors
2.1 The “explicit” SI equivalence test does not inject services
PRSC-009 requires comparison between:
provider-loaded SI services
and:
explicitly injected SI services
including stable decisions, problems, gate order, materialization identities, outputs and receipts.
The existing equivalence test creates:
explicit_pipeline = GatePipeline(
store,
active_descriptor=config.ACTIVE_PROFILE,
)but supplies no runtime_services. Therefore GatePipeline takes its ordinary loader branch again; both compared pipelines are provider-loaded. The test checks only decision outcome, problems and gate names.
GatePipeline uses explicit injection only when runtime_services is supplied.
Consequently, the current test does not establish PRSC-009’s claimed equivalence for the newly unified injection path.
2.2 The new SI cross-family classification branch is untested
The implementation correctly contains a distinct runtime branch for a claim captured against GERK or FFSNaprave while the current registry family is REGSR. It should return REVIEW_REQUIRED and must not perform a product lookup or return REVERIFIED.
That exact runtime case is required by the approved negative-case matrix.
The focused tests cover:
- rejection of GERK or FFSNaprave when constructing the SI service;
- composition-time family cross-wires; and
- generic malformed and valid registry outcomes.
They do not call the real SI service with a valid REGSR current snapshot and a cross-family captured snapshot. The focused service test file ends after the immutable-request field tests; there is no such runtime case.
Constructor rejection is not equivalent to testing the newly added claim-classification branch.
Related test-method correction
The malformed applicability and materialization tests currently replace methods on an already composed pipeline:
pipeline.runtime_services.context_assembler.assemble = ...
pipeline.runtime_services.materializer.recompute = ...The approved negative-case model says candidate implementations should enter through the provider-registration seam or explicit injection, without private-field mutation.
These tests do exercise rollback and consumer-side ordering, so this is not a third independent defect. Nevertheless, correct the setup while revising the focused suite: construct the signature-compatible faulty service before GatePipeline validation and inject that graph, as the registry-result helper already does.
Material consequence
The reported 90-test focused pass can remain green even if:
- an injected, otherwise-valid SI graph changes outputs, receipts or materialization identities relative to the loaded path; or
- the real cross-family SI branch performs a lookup or returns the wrong disposition.
Those are specifically new or changed paths introduced by this PR.
Smallest correction
Do not add a framework or another test module.
- Replace or revise the existing SI equivalence test so one pipeline is provider-loaded and the other receives the exact graph returned by
load_profile_runtime_services(...)throughruntime_services=.... Compare the contract-mapped observable fields, not only gate names. - Add one direct real-SI registry test with:
- current snapshot in exact REGSR;
- captured snapshot in GERK or FFSNaprave;
- a spy lookup that fails if invoked; and
- assertions for
REVIEW_REQUIRED,PRODUCT_BINDING_UNRESOLVED, and noREVERIFIED.
- Reuse the existing graph-copy/injection helpers for malformed applicability and materialization results.
The focused test file is already near its approved ceiling, so revise or consolidate existing tests rather than increasing the architecture budget.
What is correctly implemented
The main implementation direction is sound:
- Provider-loaded and explicitly injected graphs converge on the same Store-aware validator.
- Store, descriptor, context, specifications, materializer, output assembler, selected policy component, optional reference family, RuntimeBundle and selected-input provenance are checked at composition.
- The policy provider retains the exact selected
PROFILE_POLICYcomponent rather than treating a matching path or identifier as sufficient. - The SI provider binds the exact descriptor-owned REGSR family while product lookup semantics remain SI-private.
- Registry reverification receives a frozen detached request and returns a closed outcome; generic validation owns logging, review routing and refusal effects.
- Applicability and materialization references are checked before their respective success logs and before the materialization success flag is set.
- The synthetic implementation remains familyless and contains no common product lookup contract.
- The extra
test_runtime_bundle.pychange is a one-line mechanical digest update, not a runtime-selection change. - The lightweight exact-head checks passed. The expensive executor remains gated and was correctly skipped before a zero-blocker content review.
Authority impact
Active baseline files affected: none.
Change category: implementation/conformance correction within the approved Phase B boundary.
Smallest controlled patch: harden exception normalization in kernel/profile_runtime_provider.py, repair the focused tests described above, mechanically update the inventory and RFC implementation record, and request a focused exact-head re-review.
Final result: exact head 2d0ccff0fd12fd9577c379b9c03120c61a72c6a7 is not ready for baseline admission or merge.
Focused exact-head Phase B re-review requestedPlease review only exact head Approved Phase A authority remains:
Current RFC implementation-record identity: The correction is limited to the same private runtime-integration/readiness
No framework, module, budget increase, public extension surface, discovery, Corrected Python 3.12.13 evidence:
The exact host Please first state whether both Blockers from review #5117221048 are cleared, This PR remains draft. Re-review does not authorize merge, and no baseline |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #362 — focused exact-head Phase B implementation re-review
Reviewed exact head:
9019300e7bf66a13b2961a0c3bad9131a862d3b8 2026-09-04 22:19:21 +0200
against base 0c55f5cc6665ffef4c57591dafe014ad9bc44524 (unchanged). Head re-confirmed
immediately before writing this; still draft, mergeable_state: clean.
Previously reviewed heads by me: c47639972f and 646d24e7c4 (Phase A, documentation only).
This is my first pass on the implementation. It positions itself as a focused re-review of the two
Blockers in review 5117221048
at 2d0ccff0fd, plus an independent look at everything the correction touched and at the numbers
the PR body and §13.3 assert.
Independent extraction from a fresh anonymous clone:
15 files changed, 2919 insertions(+), 209 deletions(-) base...head
5 files changed, 121 insertions(+), 90 deletions(-) 2d0ccff..9019300 (the correction)
git diff --check base...head clean
docs/rfcs/OFARM2_Profile_Runtime_Service_Contract_Execution_RFC_v0_1.md
1496 lines 97,311 bytes
sha256:2b970f194df23f036a02e420de643f99c530fa63adff3964ddfe6e6ce79a8051
Disposition: 0 Blockers, 2 Should fix, 4 Preferences.
Both Blockers are closed. I verified each closure by running hostile graphs through the real
composition paths rather than by reading the diff, and I calibrated the new SI tests to find out
which assertion in each is actually load-bearing. The two Should-fixes are new: one is the
remaining hole in the same error boundary Blocker 1 was about, one is the half of Blocker 2.1's
consequence the new equivalence test still cannot detect. Neither admits a bad implementation.
Blocker 1 — ordinary exceptions escaping composition — CLOSED
_validate_services is now a thin normalizing wrapper around _inspect_services
(kernel/profile_runtime_provider.py:305-313), and recognized_rule_refs is type- and
element-checked before issubset (:294-301). I did not take that on trust. I built hostile
graphs and ran them through both composition paths — the explicit-injection path with the real
SI graph against a live PostgreSQL Store, and the loader path through the real registration seam
(load_profile_runtime_services(..., _registrations=(...)), the same seam
test_profile_runtime_neutrality.py uses) with a reviewer-only provider source file:
PROBE injected/recognized_rule_refs=None
-> ProfileRuntimeError(runtime policy does not match the descriptor)
PROBE injected/raising-recognized_rule_refs-property
-> ProfileRuntimeError(runtime service graph inspection failed) cause=RuntimeError
PROBE injected/raising-method-property (assemble as a raising property)
-> ProfileRuntimeError(runtime service graph inspection failed) cause=RuntimeError
PROBE loader/recognized_rule_refs=None
-> ProfileRuntimeError(runtime policy does not match the descriptor)
PROBE loader/raising-recognized_rule_refs-property
-> ProfileRuntimeError(runtime service graph inspection failed) cause=RuntimeError
PROBE commit/registry-raises-KeyError
-> ProfileRuntimeError(registry reverification service failed) cause=KeyError
The raising-property cases are the ones the previous Blocker predicted would leak
(_validate_call_forms resolves every bound method while building calls, before its own try).
They no longer do, because the whole inspection is inside the wrapper. Transaction entry stays at
zero: _runtime_table_counts(store) across kernel_record, kernel_edge, kernel_gate_log, kernel_idempotency, derived_materialization, derived_dependency_index, runtime_trace is unchanged
after the refused injection, so PRSC-004's "an injected refusal occurs before a transaction can
start" holds by measurement, not by reading.
except ProfileRuntimeError: raise / except Exception as exc: raise ProfileRuntimeError(...) from exc also preserves BaseException control flow as the correction promised.
Blocker 2 — missing SI evidence — CLOSED, with the load-bearing assertion identified
2.1 (the equivalence test does not inject). It does now. The explicit pipeline receives the
exact graph returned by load_profile_runtime_services(...) through runtime_services=, and
assert explicit_pipeline.runtime_services is injected_services proves the injected branch was
taken rather than the loader branch (test_profile_runtime_services.py:426-434). The compared
tuple grew from (decisionOutcome, problems, gate names) to seven components. See Should fix 2 for
the part of it that cannot fail.
2.2 (the real cross-family branch is untested). A direct real-SI test now runs the branch with
a REGSR current snapshot, a GERK captured snapshot, and a pytest.fail spy on
lookup_by_decision. I calibrated it, because "returns REVIEW_REQUIRED with
PRODUCT_BINDING_UNRESOLVED" is not by itself evidence that the cross-family branch ran:
PROBE cross-family GERK : disposition=REVIEW_REQUIRED reason=PRODUCT_BINDING_UNRESOLVED lookup_calls=0
PROBE same-family REGSR : disposition=REVIEW_REQUIRED reason=PRODUCT_BINDING_UNRESOLVED lookup_calls=1
The same-family unresolved path produces the identical disposition and reason code. So the
disposition and reasonCode assertions in that test discriminate nothing; the spy is the entire
test. It is present, so the Blocker is closed — but if a future consolidation drops or weakens the
spy, the test keeps passing while testing nothing. Worth one comment on the line, or an explicit
call-count assertion instead of pytest.fail.
Related correction (private-field mutation). The malformed applicability and materialization
tests now build the faulty service from _resolve_si_factory()(store, descriptor) before
composition and inject the graph, instead of mutating an already-composed pipeline. That is what
was asked for. Both still pass with the exact rollback assertion.
Should fix 1 — the composition error boundary still leaks when the factory itself fails
load_profile_runtime_services ends with
return _validate_services(factory(store, descriptor), descriptor, store)factory(store, descriptor) is evaluated as an argument, i.e. outside the normalization the
correction just added. Everything the factory raises while building the graph crosses the boundary
unchanged. Measured on the real loader seam (each probe in its own process, because the provider
attestation cache admits one factory per module per process):
PROBE loader/factory-raises-TypeError -> LEAK TypeError(provider factory is broken)
PROBE loader/real-policy-construction -> LEAK ProfilePolicyError(
evidence-review policy lacks an operationFloor object)
The second probe is the reachable one. It performs exactly the step the SI factory performs —
DescriptorPolicyProvider.from_runtime_bundle(descriptor, policy_component, supported_checks=...)
with the bundle's own selected PROFILE_POLICY component — and ProfilePolicyError subclasses
Exception, not ProfileRuntimeError (kernel/profile_policy.py:64,
kernel/profile_runtime.py:74). So a RuntimeBundle whose selected policy document is malformed
makes GatePipeline(store) raise ProfilePolicyError; a selected reference snapshot without an
exact operational source makes Store.selected_reference_source_data raise
RuntimeBundleBindingError inside SIProductRegister.load_from_store, which leaks the same way.
Note the asymmetry the correction created: the same Store call raises RuntimeBundleBindingError
when the factory makes it and ProfileRuntimeError when _validate_registry_binding makes it,
because only the second is inside the wrapper.
Counter-argument, stated plainly. This is not a regression: base did the same, ProfilePolicyError
is a deliberate typed error rather than one of the three "incidental" types PRSC-007 names, and
§8's PRSC-007 rows are about graphs that are returned, not graphs that fail to be built. The
registration set is code-owned and closed to the SI provider, so no untrusted party chooses the
factory. That is why this is a Should fix and not a Blocker. But the PR's own claim is that
composition has one stable error contract, and this is a one-line gap in it, in the same function
the Blocker-1 correction edited.
Smallest correction. Move the factory call inside the normalization:
def load_profile_runtime_services(...):
...
try:
services = factory(store, descriptor)
except ProfileRuntimeError:
raise
except Exception as exc:
raise ProfileRuntimeError("runtime factory failed to construct services") from exc
return _validate_services(services, descriptor, store)plus one hostile case in the focused suite. If the boundary is instead intended to stop at the
returned graph, say so in §6.1 — right now §7 PRSC-007 and the §13.3 record read as if it does not.
Should fix 2 — the outputs/receipts half of the PRSC-009 equivalence assertion cannot fail
observables(...) (test_profile_runtime_services.py:448-461) compares seven components. Three of
them — view["body"], view["runtimeReceipt"]["runtimeBundleDigest"],
frozenset(view["runtimeReceipt"]["payloadDigests"]) — are produced by calling
passport_view(demo.FARM, demo.FARMER, allow_recompute=False) and never read result. Both
calls happen after both commits, against the same farm-global Store state, through two assemblers
of the same class bound to the same Store and specification. I ran all four (pipeline, result)
pairings:
PROBE combo default/default : differs in nothing
PROBE combo explicit/explicit : differs in nothing
PROBE combo explicit-pipeline/default-result : differs in nothing
PROBE combo default-pipeline/explicit-result : differs in nothing
Swapping which commit the tuple describes changes nothing, which is the signature of a comparison
that carries no information about the individual commit. The discriminating components are the
trace-derived ones (decisionOutcome, problems, (gate, outcome) sequence, and the
materialization refs — and those only as (ref-prefix, schemaVersion) pairs, not identities).
This matters because it is precisely the consequence the previous Blocker 2.1 named: "the focused
pass can remain green even if an injected, otherwise-valid SI graph changes outputs, receipts or
materialization identities relative to the loaded path." The gate-order and decision half of that
is now genuinely covered. The outputs-and-receipts half is nominally present and structurally
unfalsifiable: a difference in what each commit wrote is invisible, because both views read the
union of both commits' effects.
Smallest correction. Compare each commit's own artifacts rather than a shared post-commit view.
The commit result already carries them: emittedAssertionRecordRefs,
emittedAcceptedConsequenceRefs, inForceArtifactRefs, plus the trace's
evidenceSufficiencyCaseRef and the PACK_PROFILE_APPLICABILITY / CURRENT_STATE_MATERIALIZATION
relatedArtifactRefs. Fetching each payload and comparing it with minted ids and timestamps
normalized (the RFC's own "normalizing only minted IDs/timestamps that were already volatile")
gives an assertion that can actually fail. This is a revision of one existing test, not a new
module — but see Preference 1 about where the lines come from.
Preferences
P1 — the focused test module sits exactly on its authorized ceiling.
kernel/tests/test_profile_runtime_services.py is 1,200/1,200. Any in-boundary test correction
— including Should fix 2 — must be paid for by consolidating existing lines, or it hits stop
condition 10 and needs a new contract. Counter-argument: three other repository test modules sit
exactly at their cap (test_security_audit_process_crash.py 1,250/1,250,
test_security_audit_hmac_retirement.py and test_security_audit_runtime_cross_slice.py both
800/800), so "at cap" is house practice, not a defect. I raise it only because this PR has now had
seven review rounds and each one added focused evidence.
P2 — composition scans the selected reference sources two or three times. Measured by counting
calls to Store.selected_reference_source_data during one construction:
GatePipeline(store) -> 2 calls (SIProductRegister.load_from_store, then
_validate_registry_binding)
load_profile_runtime_services(...) -> 2 calls
then GatePipeline(store, runtime_services=...) -> 1 more
Counter-argument, and the reason this is only a Preference: the validator's re-derivation is the
point — comparing provider-supplied provenance against a value the provider did not produce is
what makes PRSC-003 meaningful. A cached value would weaken the check. Worth one comment saying so,
since EXC-002 readers will otherwise see duplicate work.
P3 — _bind_route_resolution compares descriptors by value. kernel/gates.py:223 uses
descriptor != self.runtime_services.descriptor where the rest of this contract insists on is
identity for "the exact Store-bound descriptor object". Pre-existing, unchanged by this PR, and
resolve_bound_descriptor may already collapse it to the same object — but it is the one remaining
value-equality comparison on the descriptor at a runtime seam. Follow-up material, not this PR.
P4 — the consolidation dropped the only ctx.runtime_services is services assertion. The
deleted test_gate_pipeline_threads_si_reference_bindings was the one place asserting that the
GateContext receives the composition root's exact graph object. At head:
grep -rn "runtime_services is" kernel/tests/*.py
test_profile_runtime_services.py:434 explicit_pipeline.runtime_services is injected_services
test_profile_runtime_services.py:682 first.runtime_services is not second.runtime_services
Nothing asserts the context identity any more. kernel/gates.py:157 passes
runtime_services=self.runtime_services and the property is exercised by every commit test — but a
regression that made _new_context load a fresh, equivalent graph per commit would leave the whole
suite green while silently breaking the one-composition-root property (EXC-001) this PR exists to
establish. One line restores it, if one can be freed inside the ceiling (see P1). I put it at
Preference rather than Should fix because §13.3 discloses the consolidation and the assertion it
replaces is genuinely cheap.
Evidence I ran, and what it says about the PR's own numbers
Environment: CPython 3.12.3 (not the supported 3.12.13), PostgreSQL 16.13 on a unix socket
matching kernel/config.database_dsn(), locked review venv from
requirements-review-pip.lock + requirements-review-baseline.lock with --require-hashes,
pip check clean. Ruff 0.15.5 from requirements-review-tools.lock.
| Claim (PR body / §13.3) | My measurement | Verdict |
|---|---|---|
| focused hostile + neutrality: 89 passed | test_profile_runtime_services.py 87 + test_profile_runtime_neutrality.py 2 = 89 passed |
matches |
| review inventory: 3,915 pinned tests | _load_test_inventory(cfg) accepts (canonical, sorted, unique, entriesSha256 reproduces); entryCount 3,915 |
matches |
| inventory is not stale | pytest kernel/tests --collect-only -q → 3,915 collected; set difference against the inventory node ids: 0 missing, 0 unexpected |
matches |
| runtime-bundle receipt assertion: 1 passed | test_runtime_bundle.py 199 passed, including the updated sha256:a66f6d11… closed-set digest — the mechanical update reproduces from the head sources |
matches |
| generated manifest verification: PASS | python -m kernel.manifest --verify-generated → PASS at head and at base |
matches |
| targeted Ruff over changed files: PASS | ruff check over the 13 changed .py files → All checks passed! |
matches |
git diff --check: PASS |
clean | matches |
| package contract check: PASS | refuses here (UNSUPPORTED_PYTHON_VERSION) — identical 2 failures at base and head |
environmental, not PR-caused |
| rewrite architecture check: PASS | refuses here for the same reason; I re-did its budget arithmetic (below) | see below |
| extraction check base/head sets | reproduced exactly (below) | matches |
| Kernel regression: 2,907 passed, 6 skipped | mine differs by environment (below) | see below |
Architecture budgets. conformance/rewrite_architecture_check.py demands exactly CPython
3.12.13; uv python install 3.12.13 still answers "No download found". So I did not run the
checker — I loaded MODULE_BUDGETS, COMMAND_MODULE_BUDGETS, GROUP_BUDGETS,
TEST_MODULE_BUDGETS, MAX_TEST_LINES and TEST_GLOBS from the head file by AST and applied its
own _line_count (len(source_text.splitlines())) myself. That covers §10's arithmetic and
nothing else about the check:
module overruns across every budget table: none
group "profile runtime": 1020 / 1050
kernel/profile_runtime_provider.py 340 / 350 (PR-specific cap 340 — exactly at it)
kernel/provider_import_policy.py 251 / 260 (fixed at base count 251 — unchanged)
kernel/profile_runtime_services.py 294 / 295
kernel/profiles/si_ffs/runtime_provider.py 91 / 120 (PR-specific cap 100)
kernel/profiles/si_ffs/manifest_inputs.py 44 / 90 (fixed at base count 44 — unchanged)
test kernel/tests/test_profile_runtime_services.py 1200 / 1200 AT CAP
test kernel/tests/test_profile_runtime_neutrality.py 246 / 800
test kernel/tests/_synthetic_profile_runtime.py 237 / 800
test kernel/tests/_profile_runtime_test_support.py 630 / 800
Every §13.3 count is exact, the §10 maximum authorized group spend of 1,030 is not exceeded (1,020),
and the checker's diff contains exactly the three authorized ceiling edits (250→295,
900→1,050, and the new 1,200 test-module override) and nothing else. I also swept the whole
repository for anything else that pins those constants — this was the direction my Phase A pass
left open, and it is now checked beyond test_rewrite_architecture_check.py:
grep -rn "GROUP_BUDGETS|TEST_MODULE_BUDGETS|MAX_TEST_LINES|MODULE_BUDGETS" kernel/tests/*.py conformance/*.py
-> kernel/tests/test_security_audit_observer_root_admission.py:1368 (MODULE_BUDGETS[observer_root] only)
No test asserts any of the three changed values, so the edits need no companion change outside the
§11 boundary.
Extraction consistency. Reproduced both sides with my probe files removed from the tree:
base 0c55f5cc : FAIL (3 failures) conformance/review_baseline_test_inventory.json
kernel/tests/_synthetic_profile_runtime.py
kernel/tests/test_rewrite_architecture_check.py exit 1
head 9019300e : FAIL (2 failures) conformance/review_baseline_test_inventory.json
kernel/tests/test_rewrite_architecture_check.py exit 1
Strict subset, no added path, retained diagnostics byte-identical. The single removal is explained
and true: the fixture's module docstring went from "Synthetic non-SI services used only to
prove the neutral runtime seam" to "Synthetic services used only to prove the profile-neutral
runtime seam", and no other seed term remains in that file. §13.2's criterion is met.
Kernel regression. The whole suite in one process crashes the runner in this container
(TypeError: 'NoneType' object is not callable inside pytest's traceback formatter — some earlier
module leaves os.stat unusable at teardown), so I ran all 91 test modules one process each:
2,951 passed, 308 skipped, 219 failed, 103 errors
Every failure and error comes from seven modules, and all seven produce identical counts at the
base commit in this same environment:
test_postgresql_migration_runner.py / test_postgresql_provisioning.py
base and head: 4 failed, 93 passed, 103 errors (PG 16.13,
not the pinned exact-Debian PostgreSQL 17.10 build)
test_temporal_contract_governance.py base and head: 211 failed, 157 passed
test_rewrite_architecture.py base and head: 1 failed (UNSUPPORTED_PYTHON_VERSION)
test_security_audit_observer_root_admission.py, test_temporal_carriers.py,
test_tenant_command_runtime_bundle_selection.py
base and head: 1 failed each (repository tooling absent here)
So: no head-only failure anywhere in the Kernel suite. My totals differ from the PR's 2,907/6
because my environment excludes different things, not because we disagree about the code.
Post-approval RFC drift. The one that would invalidate the whole authority chain if it were
wrong:
sha256(RFC @ aa6956e4dd) = 1fd3d3397082d4821a6f46806622aa5a6ac901a5e0ad1b8a07f656e72b056988
PR body / §13.3 claim = 1fd3d3397082d4821a6f46806622aa5a6ac901a5e0ad1b8a07f656e72b056988
git diff aa6956e..head -- <RFC> = 87 insertions, 2 deletions, in exactly two hunks:
the status header, and §13.3 (Phase B implementation record)
§10's ceilings, §11's boundary, the invariants, the negative-case matrix and the stop conditions
are byte-identical to the approved head. The architecture edits were authorized before they were
made, not after.
Checked, and decided were not findings
kernel/tests/test_runtime_bundle.pyis the 15th changed file and is not in the §11 list.
The change is one expected-digest literal, §11's "purely mechanical" escape covers it, §13.3
discloses it, andtest_runtime_bundle.pypasses 199/199 — i.e. the new digest genuinely
reproduces from the head's selected source bytes. Nothing else in the repository carries the old
or new digest except that assertion and the §13.3 record.- The two tests the correction deleted.
test_gate_pipeline_threads_si_reference_bindings
assertedrevalidator.product_lookup.bindings.regsr_snapshot_prefix == revalidator.snapshot_prefix; that is now enforced in production code
(kernel/validators.py:1088-1089), which is stronger than a test.
test_issue_159_default_pipeline_selects_registered_si_provider's descriptor assertion was
folded into the equivalence test. One assertion did not survive — see Preference 4. - Production call-form inventory vs the implementation. I re-derived the inventory by grepping
every production call site of the eight service methods (excludingkernel/tests/) and compared
it row by row against_validate_call_forms's 15 rows and §6.2's 15-row table. They agree
exactly, including the zero-argumentevidence_policy()self-call at
kernel/profile_policy.py:479that was my Phase A finding, and bothresolve_for_useshapes at
si_ffs/outputs.py:274and:448. No production call form is missing; PRSC-001's admission set
is complete at this head. - TOCTOU on a validated graph.
ProfileRuntimeServicesattributes stay mutable after
validation. §6.6 excludes post-validation mutation by trust model and explicitly refuses a lock,
copy, proxy or per-call revalidation, so this is a stated design choice, not a gap. recognized_rule_refsat time of use.kernel/validators.py:1347reads it for
ComplianceClaimValidator; the new composition-timefrozenset[str]check is what makes that
read safe, and §6.6 covers the rest.SIProductRegister.load_from_storereordering. The Store call is now hoisted above
self.bindings = …and_by_snapshot.clear(), so a failing scan leaves the register untouched
instead of half-updated. Selected rows, payloads, indexes and lookup behavior are unchanged on
the success path, which is what §11 authorizes.- Ruff over the whole repository reports 3 errors —
F401in
kernel/profiles/si_ffs/si_bindings.py,F402inkernel/runtime_bundle.py, and oneE702—
identical at base. Pre-existing, outside this boundary. _validate_servicesnormalizingRuntimeBundleBindingErrorintoProfileRuntimeErrorwhen
the Store scan fails inside_validate_registry_binding. Arguably it hides a real bundle-binding
fault behind a runtime error, but PRSC-007 asks for exactly this, so it is the contract's own
choice.
What my method made easier than production
- PostgreSQL 16.13, not the pinned exact-Debian 17.10 build. The Kernel Store does not enforce
the 17.10 pin the way the security-audit provisioning path does, so the profile-runtime evidence
runs — but every provisioning, migration-runner and audit-posture test that does enforce it
skipped or failed here at base and head alike. Nothing in this review is evidence about those. - CPython 3.12.3, not 3.12.13. The architecture and package-contract checks refuse outright. I
re-implemented only the §10 budget arithmetic from the checker's own tables; I did not
reproduce its import-bound, function-length, AST, formatter or profile-neutrality checks, and a
violation there would be invisible to me. The PR's "rewrite architecture check: PASS" is
therefore unverified by me except for the budgets. - Per-module test runs. The single-process whole-suite run crashes the runner here, so cross-
module ordering effects are outside my evidence — including the provider-attestation cache in
provider_import_policy.py, which forced my own loader probes into one process each. A defect
that only appears when two provider admissions share a process would not show up. - The loader probes use a
SimpleNamespaceStore stand-in (the pattern
test_profile_runtime_neutrality.pyalready uses), which removes the startup, route and
real-bundle checks that precede composition in production. The injected-path probes, by
contrast, ran against the real Store on a live database, which is where the transaction-count
assertions come from. - I did not run the hosted expensive baselines, the native-verifier workflows, or anything
requiring repository credentials. - Account provenance. This review, like the seven before it, is posted from the PR-author
account. It is exact-head technical review; it is not independent authorship, and it should not
be counted toward a two-independent-reviewer gate.
Authority impact
Active baseline files affected: none.
Change category: implementation/conformance correction inside the approved Phase B boundary.
Result: exact head 9019300e7bf66a13b2961a0c3bad9131a862d3b8 has zero demonstrated in-scope
Blockers. Both prior Blockers are closed and verified by execution. The two Should-fixes are
in-boundary and small; Should fix 1 is one line of production code plus one hostile case, Should
fix 2 is a revision of one existing test that must fit inside the module's already-exhausted
1,200-line ceiling.
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #362 — focused exact-head Phase B re-review
Reviewed exact head:
9019300e7bf66a13b2961a0c3bad9131a862d3b8
against the previously reviewed implementation head:
2d0ccff0fd12fd9577c379b9c03120c61a72c6a7
and original base:
0c55f5cc6665ffef4c57591dafe014ad9bc44524
The head remains open, mergeable, and draft. The corrective change is one commit; the complete PR still contains 15 changed files.
Disposition
0 Blockers.
Both findings from review 5117221048 are closed without redesign or scope expansion. I found no new in-scope Blocker in the corrective commit.
This exact head is ready for baseline admission and the required hosted evidence sequence. It is not yet ready for merge, and this review does not provide final merge authorization.
Previous Blocker 1 — closed
The composition boundary now consistently normalizes malformed candidate-graph inspection into ProfileRuntimeError.
The implementation separates the inspection body into _inspect_services(...) and wraps the complete call from _validate_services(...):
try:
return _inspect_services(services, descriptor, expected_store)
except ProfileRuntimeError:
raise
except Exception as exc:
raise ProfileRuntimeError(
"runtime service graph inspection failed"
) from excThis wrapper encloses protocol checks, candidate attribute access, callable extraction, signature inspection, cross-binding checks, selected-input inspection, and policy metadata inspection. Ordinary property or attribute failures therefore no longer escape as incidental exception types. BaseException control-flow signals remain outside the catch, as required.
recognized_rule_refs is now checked before the set operation:
type(recognized) is frozenset
all members are non-empty built-in strings
required_rules.issubset(recognized)A None, list, malformed member, or other incorrectly typed value can no longer reach frozenset.issubset(...) and leak a raw TypeError.
The focused hostile matrix adds rule_refs_type, and the existing parameterized test runs that defect through both:
GatePipeline(..., runtime_services=...)
load_profile_runtime_services(...)
It also retains the assertion that neither refusal path enters a transaction.
Result: PRSC-007’s stable composition-error boundary is now implemented for the demonstrated counterexample.
Previous Blocker 2 — closed
Explicit injection is now genuinely exercised
The revised SI equivalence test now obtains an admitted service graph with:
injected_services = load_profile_runtime_services(...)and supplies that exact graph through:
GatePipeline(
store,
active_descriptor=config.ACTIVE_PROFILE,
runtime_services=injected_services,
)It also asserts that the pipeline retains the injected graph by identity. This reaches the explicit-injection branch rather than loading a second graph implicitly.
The comparison is no longer limited to terminal outcomes and gate names. It covers:
- decision outcome and problems;
- ordered gate/outcome pairs;
- materialization reference families and contract kinds;
- PassportView body;
- RuntimeBundle receipt digest; and
- receipt payload-digest membership.
That is proportionate evidence for the private loader-versus-injection invariant without creating a second test framework or attempting byte equality over intentionally minted identifiers and timestamps.
The real SI cross-family runtime branch is now exercised
The revised test uses the actual SI registry service from a live composed graph, preserves its exact REGSR binding, and installs a lookup spy that fails if called. It then supplies:
current snapshot: REGSR
captured snapshot: GERK
verified crop-protection-product binding
The test requires:
REVIEW_REQUIRED
PRODUCT_BINDING_UNRESOLVED
no product lookup
This directly exercises the new claim-classification branch rather than merely testing constructor rejection for the wrong family.
Faulty consumer-result implementations now enter before composition
The malformed applicability and materialization cases now:
- construct a candidate service graph;
- replace the relevant implementation before admission;
- explicitly inject that graph through
GatePipeline; and - run the real commit transaction.
They no longer mutate an already admitted pipeline graph. The tests still verify full transaction rollback after the malformed runtime result.
Result: the missing PRSC-005, PRSC-006, PRSC-007, and PRSC-009 evidence identified in the prior review is now present.
Focused regression and drift audit
The production correction changes only kernel/profile_runtime_provider.py: one explicit policy-metadata validation and one outer exception-normalization boundary. The remaining corrective files are focused tests, the mechanical test inventory, the RFC implementation record, and the RuntimeBundle digest assertion necessitated by changed selected Python source bytes.
No common product lookup, product-role vocabulary, dynamic discovery, plugin framework, capability bag, profile composition, multi-family abstraction, Serbian runtime, or new authority was added.
The consolidation removes two overlapping SI wiring tests while adding the malformed-metadata case, resulting in 3,915 inventory entries rather than 3,916. The retained tests now carry the removed wiring assertions as part of stronger behavioral cases.
The implementation remains within the approved limits reported at the current head:
profile_runtime_services.py 294
profile_runtime_provider.py 340
SI runtime provider 91
focused service test 1,200
profile-runtime source group 1,020
The provider and focused test are exactly at their approved PR-specific ceilings, so further growth would require consolidation or a new authorization. That is not a current Blocker.
GitHub currently shows the lightweight package/workflow check passing. The expensive executor is skipped, which is the correct pre-admission state under the repository’s review ordering.
Classification
Blockers: none.
Follow-ups: none arising from this corrective commit.
Preferences: none required before admission.
Authority impact
Active baseline files affected: none.
Change category: implementation/conformance correction within the approved Phase B capability and trust boundary.
Final result: exact head 9019300e7bf66a13b2961a0c3bad9131a862d3b8 has zero demonstrated in-scope Blockers and is ready for baseline admission. It remains draft and must not merge until the admitted hosted evidence, publication/evidence requirements, final exact-head packet, and separate task-user merge authorization are complete.
Keep provider construction failures inside the private composition error contract and strengthen SI equivalence evidence by observing each isolated commit's own artifacts and receipt. Regenerate the pinned test inventory and reviewed RuntimeBundle digest for issue #160.
Exact-head Phase B re-review requestedPlease review only exact head This one correction commit addresses the two Should-fixes in review
The provider and focused test remain at their approved 340-line and 1,200-line Supported Python 3.12.13 evidence at this exact code shape:
Please classify any finding under |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
PR #362 — focused exact-head Phase B re-review
Reviewed exact head:
9ae9fad029477583f66e9b0efac57c4ebef4bec5
against the previously reviewed head:
9019300e7bf66a13b2961a0c3bad9131a862d3b8
and original base:
0c55f5cc6665ffef4c57591dafe014ad9bc44524
The PR remains open, mergeable, and draft. The correction is one commit on top of the previous zero-blocker implementation head.
Disposition
0 Blockers.
0 remaining Should-fixes from review 5117870936.
The two requested corrections are implemented without redesign, authority expansion, or boundary drift. This exact head is ready for baseline admission and the required hosted evidence sequence. It is not ready for merge, and this review does not authorize merge.
Should-fix 1 — factory-construction error boundary closed
load_profile_runtime_services(...) now invokes the admitted factory inside an explicit normalization boundary:
try:
services = factory(store, descriptor)
except ProfileRuntimeError:
raise
except Exception as exc:
raise ProfileRuntimeError(
"runtime factory failed to construct services"
) from excThe returned graph then continues through the existing Store-aware _validate_services(...) boundary. This has the required semantics:
- deliberate
ProfileRuntimeErrorremains unchanged; - ordinary construction failures, including
TypeError,ProfilePolicyError, and Store/reference-data construction failures, becomeProfileRuntimeErrorwith their cause preserved; BaseExceptioncontrol-flow signals are not swallowed; and- no second composition authority or wrapper abstraction is introduced.
The focused test supplies a factory that raises TypeError, requires ProfileRuntimeError, and verifies that the original TypeError remains the cause. This directly exercises the previously uncovered evaluation point rather than merely testing graph inspection after a factory successfully returns.
The correction completes the demonstrated PRSC-007 exception-boundary gap. I found no remaining ordinary factory-construction path outside this new boundary. Provider source resolution and import retain their existing separately governed ProviderImportError handling.
Should-fix 2 — branch-local SI equivalence evidence closed
The SI equivalence test now genuinely compares the two composition paths:
default provider-loaded pipeline
explicit pipeline receiving a loader-returned runtime-services graph
The explicit pipeline receives runtime_services=injected_services, and the test verifies that it retains that exact graph object. It no longer constructs two implicitly loaded pipelines.
More importantly, both pipelines now process the same submission from the same starting database state inside separate force_rollback=True transaction scopes. Each branch is observed before its outer transaction rolls back. The comparison includes:
- the complete normalized
CommitIngressResult; - the complete normalized
PromotionTrace; - every referenced event, sufficiency, assertion, review, consequence, materialization-basis, and materialization-snapshot payload selected by the test;
- the deterministic materialization key;
- that branch’s own PassportView body, metadata, and qualification;
- RuntimeBundle digest; and
- receipt payload-digest key structure.
Only known server-generated timestamps and minted identifiers are normalized. Event semantics, policy identities, materialization-key content, output content, qualifications, gate outcomes, and nonvolatile references remain comparison-sensitive.
This fixes the previous shared-post-commit-state defect. The first branch’s effects are rolled back before the second branch runs, so the second PassportView cannot make the comparison pass merely by reading the union of both commits.
Comparing receipt payload-digest keys rather than their raw values is appropriate here because the raw payloads contain deliberately variable IDs and server timestamps. The normalized payloads themselves are compared separately and in full; the receipt comparison verifies the corresponding structure and exact RuntimeBundle identity without treating permitted volatility as a semantic difference.
Focused scope and drift audit
The corrective commit changes only:
- factory invocation normalization in
kernel/profile_runtime_provider.py; - the focused equivalence and hostile tests;
- the mechanical test inventory;
- the RFC implementation record; and
- the expected RuntimeBundle digest caused by the selected provider-source byte change.
No service protocol, registry behavior, profile semantic rule, selected reference input, output implementation, schema, manifest, activation, provider-registration model, or baseline law changed.
I found no introduction of:
- a public plugin API;
- dynamic discovery;
- a capability bag;
- generic product or country vocabulary;
- profile composition;
- a multi-family abstraction;
- Serbian runtime execution; or
- another validation or authority path.
The implementation remains at the approved local caps reported by the PR:
profile_runtime_provider.py 340
profile_runtime_services.py 294
SI runtime provider 91
focused service test 1,200
profile-runtime source group 1,020
The production provider and focused test are exactly at their PR-specific ceilings. That is not a current defect, but any further change must consolidate existing lines or obtain new authority rather than silently raising those limits.
GitHub’s lightweight package/workflow check passed at this exact head. The expensive executor remains skipped, which is the correct state before baseline admission.
The locally reported Python 3.12.13 counts were not independently re-executed in this connector review. Their progression is internally consistent with the added factory-failure test and updated inventory, but they remain local evidence until the admitted hosted sequence runs.
Classification
Blockers: none.
Should-fixes: both prior items closed.
Follow-ups: none introduced by this correction.
Preferences: the previously noted exact-cap constraint remains non-blocking; no additional preference is required before admission.
Authority impact
Active baseline files affected: none.
Change category: implementation/conformance correction within the already approved Phase B capability and private runtime-integration trust boundary.
Final result: exact head 9ae9fad029477583f66e9b0efac57c4ebef4bec5 has zero demonstrated in-scope Blockers and is ready for baseline admission. It remains draft and must not merge until the required admitted hosted evidence, publication and receipt gates, final exact-head packet, and separate task-user merge authorization are complete.
|
Baseline admission follows exact-head zero-Blocker review 5118081437 and the task user's explicit approval. OFARM2_BASELINE_ADMISSION |
1 participant
Closes #160.
Status
Phase B implementation and all applicable technical/evidence gates are complete
at exact head
9ae9fad029477583f66e9b0efac57c4ebef4bec5. The PR is open,non-draft, mergeable, and ready for the task user's final exact-head review. It
remains unmerged. No prior approval, review, admission, check, or evidence
artifact authorizes merge or any production-readiness claim.
The durable design and implementation record is
OFARM2 Profile-Runtime Service Contract Execution — Phase A Contract v0.1.
Phase A authority:
0c55f5cc6665ffef4c57591dafe014ad9bc44524;aa6956e4dd2c795c9acc0c980b5d299b2d13f030;1fd3d3397082d4821a6f46806622aa5a6ac901a5e0ad1b8a07f656e72b056988;Phase B review 5117221048
found two in-boundary blockers at
2d0ccff0fd12fd9577c379b9c03120c61a72c6a7.Head
9019300e7bf66a13b2961a0c3bad9131a862d3b8closed both and received twoexact-head zero-blocker reviews:
5117870936
and 5117870979.
The first requested two in-boundary should-fixes before baseline. This head
normalizes ordinary provider-factory construction failures at composition and
reworks SI equivalence evidence so each branch is observed against its own
isolated commit state, artifacts, materialization, view, and receipt.
Trust boundary and implemented capability
Primary trust boundary: runtime integration and readiness at the private
profile-runtime service/composition boundary.
This PR:
orchestration, including all
MaterializationGateinvalidation keywords;Store-aware composition validator;
materializers, output assemblers, policy components/references, capability
families, selected registry inputs, missing callables, incompatible
signatures, and malformed rule-reference metadata before governed work
starts;
ProfileRuntimeErrorwhile preserving deliberateProfileRuntimeErrorandBaseExceptioncontrol flow;APPLICABLEorUPDATEDcan be logged;and closed outcome enum while keeping every generic effect code-owned;
component, RuntimeBundle, input identities, and descriptor-owned REGSR
family without moving product semantics into the common Kernel; and
applicability, registry, and materialization stages without SI identifier
leakage or production registration.
Existing SI outcomes, materialization identities, outputs, receipts, selected
data, and gate ordering remain assertion-equivalent for unchanged inputs.
Verification
Supported local environment: Python 3.12.13.
files excluded: 2,908 passed, 6 skipped, 2 third-party warnings;
database: PASS;
git diff --check: PASS; andApproved ceilings remain satisfied: the provider is 340 lines, the service
contract is 294, the SI provider is 91, the focused service test is 1,200, and
the runtime source group is 1,020. The regenerated RuntimeBundle digest is
sha256:8816a0097d230cf7d165aca2ea54faca8f41794131be35a17363630f959f497f.The unmodified complete Kernel command was also run and is not presented as a
pass: 3,501 passed, 7 skipped, 7 failed, 401 setup errors. Every non-pass
was in the same 23 live PostgreSQL files. The repository refused the available
macOS PostgreSQL 17.10 server because it is not the required exact Debian build
17.10-1.pgdg13+1; subsequent cases observed the intentionally uncreatedservice databases.
The exact host
python3is 3.14.5. The exact architecture and package commandsrefused it as
UNSUPPORTED_PYTHON_VERSION, and exact manifest verificationlacked
psycopg. Their repository-supported Python 3.12.13 equivalents passedas reported above.
Extraction consistency remains honestly non-zero. The exact base failure-path
set was:
The current head is the strict subset:
No path was added and retained diagnostics are unchanged. The permitted
synthetic fixture rewrite removed its incidental
non-SIdocstring seed term;no extraction inventory authority changed.
Hosted evidence and publication
reports zero Blockers and zero remaining Should-fixes at
9ae9fad....remains created-and-unedited and binds that full head SHA with
blockers=0.succeeded at attempt 1. Its execution merge has exact parents
0c55f5cc...and9ae9fad..., and its tree is exactly the candidatehead tree. Both reproducibility runs collected and passed all 3,916 pinned
tests with zero failures, errors, skips, collection errors, or unexpected
warnings; their normalized evidence is identical.
succeeded at attempt 1 and published the review baseline, platform evidence,
both native-verifier architectures, and native index. The final receipt was
uploaded last as artifact
9956348630, digestsha256:1e527d64e4880763e059f436dfc48ef2fe436a17a41fb2bd3bd2e2af8f68801f;it binds the live admission, both workflow identities, all four source
artifact IDs/digests, and all five authoritative artifact IDs/digests.
mainhas no branch protection and norulesets. These are authoritative workflow artifacts, not a
GitHub-enforced merge requirement.
Scope and required non-effects
The implementation stayed inside the approved private runtime integration and
readiness boundary. The test inventory and expected RuntimeBundle digest are
mechanical consequences of the focused test and selected Python source changes;
they do not change runtime authority.
No public plugin API, dynamic discovery, profile composition, schema,
migration, manifest, ActiveArtifactSet, evidence lane, capability, activation,
canonical law, provider-import posture, SI policy/default, reference payload or
lookup behavior, authorization, database/deployment/security-audit work, or
production-readiness claim is introduced. Serbia remains descriptorless,
unregistered, and unexecutable. Blocked #353/#359 is untouched.
The RFC contains the complete authority map, ordering,
invariant-to-code-to-test traceability, hostile cases, non-goals, stop
conditions, and implementation evidence.