Conversation
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
Review disposition: Request three bounded changes
Reviewed PR #23 at exact head 965c691ecd2c89d6a0b28c2d2abeeeda3bee7c7c against:
- issue #22’s protected-effect boundary and acceptance criteria;
- the active Constitution’s temporal law;
- the accepted Source Truth Record Closure and Event Ingress RFCs;
- the Event Grammar and Temporal Field Conformance Matrix;
- the accepted quantity-bearing intervention/as-applied law;
- the exact approved PR #11 authorization candidate at
03a21f6; and - the exact approved PR #20 transaction candidate at
98f8c4f.
The PR is correctly limited to one draft, non-authoritative candidate file. It is open, mergeable, and changes no active law, schemas, runtime, currentness, or OFARM2 implementation. The declared dependency heads have exact-head steward approval, and PR #20 correctly leaves NOT_REQUIRED outside its covered transaction modes. Both reported repository validations pass.
The core protected-effect design is mostly disciplined, but three semantics are not yet safe to approve.
1. Blocker — assertion subtype is incorrectly used to fix the primary event family
Section 7.2 fixes this map:
ASSERT_STRUCTURE→StructureEventASSERT_OPERATION_CLAIM→InterventionEventASSERT_COMPLIANCE→GovernanceEvent
PC_ACTION_TYPE then makes any other family fail the contract. The candidate describes the selected family as classifying both the assertion-submission act and its claimed domain context.
That conflates three different things:
- the
AssertionRecordcommit class; - the world event or governed act being described;
- the platform act of submitting the assertion.
Active Event Grammar explicitly separates event family from commit class. The primary family is selected from the dominant semantic consequence of the event, and one event may create records belonging to several commit classes. A commit class therefore cannot determine the event family by itself.
The accepted Event Ingress RFC also assigns primary event-family identity to the separate SemanticEventEnvelope. AssertionRecord remains a distinct source-truth record linked through the ingress result and promotion trace; it does not own the event family merely because it has a particular assertion subtype.
The active supporting fixtures demonstrate why the fixed map fails:
- an operation claim occurs under both
InterventionEventandMaterialEvent; - a compliance assertion occurs under
OccurrenceEvent,EvidenceEvent, andGovernanceEvent; - a structure assertion can be one of several commit classes emitted in a broader
StructureEvent.
These are applications of the active dominant-consequence rule, not arbitrary alternatives.
A concrete existing path already keeps an InterventionEvent envelope separate from its operation-claim AssertionRecord. The envelope carries event and record times, while the assertion carries the operation claim.
Smallest required patch
Keep the commit-class map fixed:
- structure result →
STRUCTURE_ASSERTION - operation result →
OPERATION_CLAIM - compliance result →
COMPLIANCE_ASSERTION
Remove primary event family as a derivation from the action or AssertionRecord subtype.
Where the ingress path has a governed semantic event:
- bind the exact immutable
SemanticEventEnvelopereference/revision or digest; - consume its separately validated
primaryEventFamily; - verify that its subject, scope, time, and dominant-consequence context are compatible with the assertion;
- record that binding in the protected-effect trace without copying event-envelope semantics into
AssertionRecord.
Where there is no associated semantic event, this contract should make no primary-event-family claim. If OFARM intends assertion submission itself to be a distinct event, that requires a separately governed event envelope for that submission act. It must not reuse the asserted world event’s family implicitly.
Update:
- section 1 decision 7;
- sections 7.2 and 7.3;
PC_ACTION_TYPE;- permitted derivations;
- trace requirements;
- hostile cases;
- the steward approval card.
Add at least these cases:
- a valid operation claim associated with a
MaterialEventmust not fail merely because its record commit class isOPERATION_CLAIM; - a valid compliance assertion associated with an
OccurrenceEventorEvidenceEventmust not be forced toGovernanceEvent; - changing the event family without changing the dominant event semantics must fail at the Event Ingress classification boundary, not through an assertion-subtype lookup.
No new event vocabulary or generic classifier is needed. This uses the existing Event Grammar and SemanticEventEnvelope.
2. Blocker — assertedAt collapses assertion time into record/commit time, while subjectTime remains semantically unresolved
There are two related temporal defects.
2.1 assertedAt = effectCommittedAt contradicts active temporal law
The candidate consistently maps:
assertedAt = trusted effectCommittedAt
It states that assertedAt is when the assertion enters canonical history and keeps the actual human act, ingress time, and evidence times outside the record. AR_ASSERTED_AT, the hostile cases, and the approval card all enforce that choice.
The active Constitution is explicit that OFARM truth law distinguishes assertion time from record time, alongside event, effective, review, and other temporal meanings.
The active Temporal Field Conformance Matrix reinforces this distinction. For delayed sync, OFARM must preserve separately:
- when the actor asserted or submitted the claim;
- when the platform received or synchronized it;
- when authority was evaluated;
- when the record was committed.
It also says a single timestamp must not stand in for every temporal fact merely because the implementation happens to process them together.
PR #11 likewise distinguishes subjectTime, authorizationEvaluatedAt, decisionValidUntil, and effectCommittedAt. It deliberately leaves the domain contract to preserve the assertion’s own temporal meaning rather than turning commit time into all-purpose assertion time.
The failure is observable in offline use:
actor creates/asserts claim at T1
device synchronizes at T2
protected effect commits at T3
The current candidate records only:
assertedAt = T3
T1 is lost unless some unrelated evidence happens to preserve it. That makes a delayed claim look newly asserted at commit time.
Required correction
assertedAt should be the exact governed time at which the asserting Party made, submitted, or affirmed the assertion covered by the effect-intent digest.
effectCommittedAt remains the transaction linearization time and belongs in the governed-effect receipt and transaction evidence. The two may be equal in a synchronous path, but equality must be an observed fact, not the contract definition.
For fresh-approval actions, assertedAt may equal humanActedAt only when the exact human act is contractually the assertion act. The human approver must not automatically become the asserting Party or supply its time merely by approving an agent or represented-Party submission.
For automated, represented, imported, or offline submission, the future intent or assertion-act evidence must carry the exact assertion-act time and its trust/provenance posture. If that value cannot be established, the contract must not silently substitute commit time.
Add a hostile delayed-sync case with distinct T1, T2, and T3 values and require all relevant times to remain distinguishable.
2.2 subjectTime is delegated to future schema authors rather than closed here
The candidate says the future intent and result schemas will later decide whether subjectTime is:
- an instant;
- an interval;
- an effective window;
- an intended window;
- a performed interval; or
- a compliance as-of time.
Until those schemas are written, the candidate prohibits an implementation from guessing. That is a safe stop condition, but it means the Phase A semantic contract has not yet made the decision required by issue #22. Issue #22 requires the exact subject-time binding to be identified, while PR #11 intentionally delegates domain qualification of subjectTime to this protected-effect contract.
For operation claims, accepted quantity/as-applied law already gives the relevant distinction:
- intended work has an intended time window;
- performed work has an effective execution interval;
- capture time is separate;
- a correction or dispute retains its own lineage and timing.
Smallest temporal-profile patch
Define the closed semantic posture before machine materialization:
INTENDEDoperation claim → exact intended time window;PERFORMEDoperation claim → exact effective execution interval, or an explicitly allowed occurrence-instant profile;- structure assertion → one closed effective/as-of posture or a small tagged choice;
- compliance assertion → one closed compliance as-of/effective posture or a small tagged choice.
For every admitted shape, close:
- discriminator;
- required endpoints;
- instant versus interval cardinality;
- inclusive/exclusive endpoint posture;
- UTC/date-time requirements;
- exact source pointer;
- forbidden substitutions.
This does not require a general temporal expression language. A small tagged union owned by the three body-schema branches is sufficient. If stewards cannot yet choose the structure or compliance posture, name a narrow temporal-profile prerequisite and do not mark Phase A complete.
3. Blocker — the contract makes correction assertions and supersession lineage unrepresentable
The current carrier supports supersedesAssertionRecordRef, and the accepted Source Truth Record Closure requires AssertionRecord to retain supersession lineage where relevant.
Accepted quantity/as-applied law is more specific:
- a correction is a new historical assertion, not an edit path;
- corrections supersede without deleting the original claim;
- correction and dispute payloads retain lineage.
PR #23 instead requires both assertion supersession fields to be absent and says later review and lineage are separate effects. AR_LEGACY_ABSENCE rejects any supersession field, and the migration section says this submission contract defines no lineage branch.
That is safe for a truly initial assertion, but the contract is bound to the full ASSERT_STRUCTURE, ASSERT_OPERATION_CLAIM, and ASSERT_COMPLIANCE actions. PR #11 gives each state-affecting action one protected-effect-contract binding. Once those actions point at this contract, there is no executable correction path unless the contract supports it or the authorization rule is later changed.
A correction payload hidden inside assertionBody or an ExecutionRecordPayload is not an adequate substitute for AssertionRecord lineage. It may describe corrected content while leaving the source-truth graph unable to state which prior assertion the new assertion corrects.
Smallest required patch
Choose one explicit posture.
Preferred bounded closure:
Add optional supersedesAssertionRecordBinding:
- permitted only under an explicit correction posture in the selected body schema;
- contains one logical prior-assertion ref and exactly one immutable revision ref or content digest;
- is covered by
effectIntentDigest; - is copied exactly to the result;
- does not mutate, delete, relabel, or automatically deactivate the prior assertion;
- does not imply review acceptance or current-state supersession;
- cannot affect authorization unless PR #11 is separately amended.
Keep supersededByReviewDecisionRef absent. That field describes a later review effect and should not be fabricated during assertion submission.
Add hostile cases for:
- correction posture without prior-assertion binding;
- binding to the wrong prior assertion or wrong digest;
- lineage supplied on a non-correction initial assertion;
- treating the lineage edge as acceptance, deletion, or current-state replacement.
Alternative narrow closure:
Explicitly state that v0.1 of this protected-effect contract supports initial assertions only, reject every correction-class body or payload, and open a named child issue for correction AssertionRecord submission before authorization-bundle promotion. The action rule must not imply that all valid assertion submissions are executable through this contract.
The current implicit middle position—accepting correction-capable payloads while prohibiting assertion lineage—is not sufficient.
Non-blocking governance note — the one-anchor-scope rule is a real narrowing
Current AssertionRecord v0.1 permits one or more anchor scopes, and an active late-sync operation-claim example uses both a field and a crop-cycle anchor. PR #23 reduces new v0.2 submissions to exactly one anchor copied from the single RP_SCOPE_ONE authority target.
The candidate exposes the one-scope rule and fails rather than silently dropping scopes, so I do not treat this as an independent semantic blocker. The approval card should nevertheless label it explicitly as a NARROWING and state how a claim needing field, crop-cycle, and operation context is represented without loss:
- one authority-bearing anchor;
- typed subject;
- exact body context; and
- immutable relationship proofs.
If that representation is not lossless for a valid claim, materialization must stop rather than flattening multiple anchors into one.
What the candidate gets right
The following parts should remain:
- A narrow
AssertionRecord v0.2carrier is justified; the v0.1 carrier cannot hold the proposed immutable body, subject, evidence, and branch bindings without relying on a sidecar. - The action-to-record-subtype mappings are coherent, including the explicit
OPERATION_ASSERTIONauthorization token toOPERATION_CLAIM_ASSERTIONresult subtype mapping. - Every new submission remains
PENDING_REVIEW. - Fresh human approval authorizes submission only and does not manufacture acceptance.
- The current reporter is kept separate from the alleged performer.
- Performer authority remains
NOT_EVALUATED_BY_AUTHORIZATION. EP_NONEis correctly distinguished from an empty AssertionRecord evidence set; authorization evidence policy and source-record evidence linkage are different axes.- Evidence, body, subject, and scope bindings are immutable and exact rather than mutable or latest-version references.
- Compliance rule/policy bindings state what the claim is made against without claiming the compliance assertion is correct.
- No assertion submission creates accepted structure, accepted execution, a compliance fact, a ReviewDecision, a current-state materialization, or an implicit companion effect.
- Protected-effect failure leaves the authorization result truthful and unchanged.
- The operation-claim path correctly remains blocked on a separately governed
NOT_REQUIREDatomic transaction profile rather than borrowing fresh approval from PR #20. - Mapping and postcondition traces use truthful
PASS,FAIL,NOT_APPLICABLE, and dependency-boundNOT_EVALUATED. - Domain semantics remain inside the protected-effect contract instead of being copied into
AuthorizationPolicyBundle.
Drift and over-design assessment
No broad scope drift. The candidate remains within AssertionRecord submission semantics. It does not edit authorization, transaction coordination, review law, current-state materialization, transport, retention, database authority, or OFARM2 runtime code.
The fixed event-family map is the only material ownership drift: it takes classification owned by Event Grammar and the separate semantic-event boundary and derives it from AssertionRecord action/subtype. Removing that derivation reduces scope.
No general over-design. The future carrier, body-schema branches, immutable bindings, branch absence rules, postconditions, and validation trace are proportionate to the trust boundary. The requested corrections require no:
- generic claim language;
- temporal query language;
- new top-level event family;
- second authorization evaluator;
- workflow engine;
- mutable semantics registry;
- correction service;
- current-state mechanism.
The correction is smaller than the current design:
- consume existing event classification rather than duplicate it;
- preserve assertion time instead of overloading commit time;
- use small branch-owned temporal profiles;
- retain one optional immutable correction lineage edge.
Authority and implementation impact
No 00_active_baseline/ rewrite is justified.
The controlled follow-on impact is:
- Accepted RFC extension: AssertionRecord submission protected-effect semantics.
- Event Ingress implication: consume the existing immutable semantic-event classification; an amendment is needed only if a distinct assertion-submission event is introduced.
- Machine-contract implication:
AssertionRecord v0.2, three body-schema branches, exact temporal profiles, optional correction lineage, protected-effect contract, and validation trace. - Transaction implication: none for the two PR #20-covered modes;
NOT_REQUIREDremains a separate prerequisite. - Conformance implication: variable event-family cases, delayed assertion/sync/commit timing, intended-versus-performed temporal substitution, and correction-lineage cases.
- Currentness implication: none until separately reviewed promotion.
- OFARM2 implication: none until accepted, promoted, and byte-identically extracted.
Final assessment
- PR boundary: correct
- Dependency pins: correct and approved
- Action-to-AssertionRecord subtype map: sound
PENDING_REVIEWsubmission posture: sound- Reporter/performer separation: sound
- Evidence and protected-effect trace posture: sound
NOT_REQUIREDtransaction stop: sound- Fixed action-to-event-family derivation: must fix
assertedAt = effectCommittedAt: must fix- Branch-specific subject-time semantics: must close
- Correction/supersession lineage: must preserve or explicitly split
- Scope drift: one bounded event-classification overreach
- Architectural over-design: none
- Phase A disposition: not ready for steward semantic approval
Keep PR #23 in draft and do not approve section 17 until these three bounded changes are closed at an exact new head.
|
Re-review requested at exact head This revision addresses the three bounded blockers and the non-blocking narrowing note:
Scope remains one non-authoritative Phase A candidate file. No Event Grammar, Event Ingress, authorization, transaction, review, schema, runtime, currentness, or OFARM2 file changed. The operation path remains explicitly blocked on the separate Validation at this head:
Please re-review the exact head above for Phase A semantic approval. |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
Re-review disposition: Request one bounded change
Reviewed PR #23 at current head 97c9a985767a32bbe4722b472d83ff66f0b5086f against the previously reviewed head 965c691ecd2c89d6a0b28c2d2abeeeda3bee7c7c.
The delta is one commit modifying only the existing non-authoritative candidate document, with 207 additions and 76 deletions. PR #23 remains open, draft, mergeable, and limited to one changed file. Both current-head workflows—repository validation and generated-currentness validation—completed successfully.
Previous findings
1. Event-family ownership: closed
The candidate no longer derives a primary event family from the assertion action or subtype. Section 7.2 now fixes only:
- action;
- intent profile;
- effect-subject kind;
- AssertionRecord subtype; and
- record commit class.
Primary event family is explicitly absent from that map.
Where an immutable SemanticEventEnvelope is associated, the contract now:
- resolves exact envelope bytes;
- consumes the independently validated Event Ingress classification;
- checks subject, scope, temporal, subtype, and dominant-consequence compatibility;
- records the association only in the protected-effect trace; and
- does not copy the family into the AssertionRecord.
Where no semantic event is associated, the event-association mapping is NOT_APPLICABLE and no family value is invented. This correctly separates the world event, the assertion-submission act, and the AssertionRecord commit class.
The requested hostile cases for MaterialEvent operation claims, OccurrenceEvent or EvidenceEvent compliance assertions, and classification changes at the Event Ingress boundary are present.
2. Assertion and subject-time semantics: closed
assertedAt is no longer defined as effectCommittedAt. The revised contract closes two assertion-act postures:
TRUSTED_ONLINE_SUBMISSION: the trusted runtime supplies the assertion-act timestamp before intent validation and hashing;VERIFIED_OFFLINE_SUBMISSION: the timestamp comes from immutable assertion-act evidence binding the asserting Party or representation basis, exact assertion content, source timestamp, and the applicable time-trust policy.
humanActedAt, ingress time, authorization time, evidence capture time, subject time, and effectCommittedAt are explicitly prohibited from substituting for assertedAt.
The delayed-sync chronology is now preserved:
T1 = assertion act
T2 = receipt/synchronization
T3 = protected-effect commit
The AssertionRecord retains T1, while T2 and T3 remain in their separately owned evidence. This aligns with active multi-temporal law rather than making commit time look like claim time.
The candidate also now defines nine closed subjectTime profiles covering:
- structure as-of, effective-from, and effective interval;
- intended operation window;
- performed operation instant and interval;
- compliance as-of, effective-from, and effective interval.
The profiles close discriminators, required members, half-open interval semantics, endpoint ordering, canonical timestamp representation, source and destination posture, and payload-equality rules. This is a bounded tagged union, not a generic temporal language.
3. Correction lineage: presence and effect posture closed; target compatibility still incomplete
The candidate now supports:
INITIAL
→ supersedesAssertionRecordBinding absent
CORRECTION
→ exactly one supersedesAssertionRecordBinding required
The binding is immutable, included in the effect-intent digest, copied exactly to the new record, and prohibited from mutating, accepting, deactivating, or replacing the prior assertion in current state. supersededByReviewDecisionRef correctly remains outside initial assertion submission.
That closes the structural absence identified in the previous review. One executable gap remains.
Remaining blocker — “wrong prior assertion” has no defined meaning
Section 5.5 currently requires the correction binding only to resolve as an “actual supported AssertionRecord.” It does not define any required semantic relationship between that prior assertion and the new correction.
There is no explicit requirement that the prior assertion:
- has the same assertion subtype;
- belongs to the same tenant or deployment boundary;
- belongs to the same twin;
- shares the same authority-bearing anchor scope;
- concerns the same logical subject;
- precedes the correcting assertion; or
- is not the correcting assertion itself.
The hostile table says a binding to the “wrong prior assertion” must fail, but the normative sections do not define what makes a prior assertion wrong. Two conforming implementations could therefore disagree while validating the same bytes.
A concrete problematic record could be:
new record:
assertionType = COMPLIANCE_ASSERTION
anchor = field:A
assertionPosture = CORRECTION
supersedesAssertionRecordBinding:
prior record = OPERATION_CLAIM_ASSERTION
anchor = field:B
tenant = unrelated tenant
Under the current written rule, the prior record may be immutable, digest-valid, and an actual AssertionRecord. Nothing in AR_CORRECTION_LINEAGE or PC_CORRECTION_LINEAGE explicitly rejects the cross-subtype, cross-scope, or cross-tenant lineage edge.
This is more than a cosmetic lineage problem. It could let an actor authorized to assert within one scope create a canonical source-truth edge claiming to correct an unrelated assertion outside that scope. The prior record would remain immutable, but the new history would still contain a false correction relationship.
Smallest required patch
Define one narrow correction-target compatibility predicate owned by this protected-effect contract.
For this v0.1 candidate, require all of the following:
- Existing prior record: the binding resolves to an AssertionRecord committed before the new assertion’s transaction; self-reference and unresolved prospective references fail.
- Same subtype: the prior and new records have the same
assertionType. - Same governance boundary: immutable resolution proves the same tenant or deployment boundary and the same applicable twin.
- Same authority anchor:
- for a prior v0.2 record, the new sole anchor equals the prior sole authority-bearing anchor;
- for a prior v0.1 record with multiple anchors, the new sole anchor must exactly match one of the prior anchors, with no cross-scope inference.
- Same logical subject: the prior and new records refer to the same logical subject. A correction that changes the claimed subject identity is outside this narrow correction profile.
- Claim-lineage semantics only:
supersedesAssertionRecordBindingdenotes correction lineage between assertions. It does not by itself change the prior assertion’s claim state, review status, current-state contribution, or in-force posture.
A correction that needs to change subtype, subject identity, authority anchor, tenant, or twin should enter as a new INITIAL assertion until a separately reviewed correction-relation profile defines that broader operation. Do not let body-schema authors infer those widening rules independently.
Also make the pointer ownership unambiguous. The candidate presently describes assertionPosture as being inside assertionBody, while using /assertionPosture as a body-schema-relative pointer. State its absolute intent and result pointers, for example:
/assertionBody/assertionPosture
or explicitly state that /assertionPosture is relative to the body-schema root.
Add hostile cases for:
- cross-subtype correction;
- cross-tenant or cross-twin correction;
- prior assertion outside the new authority anchor;
- different logical subject;
- self-reference;
- prior assertion that did not exist before the correcting commit.
This is one local domain-lineage predicate. It requires no authorization amendment, transaction change, correction service, or new contract family.
Non-blocking metadata correction
The PR description still requests review of the superseded design. It says:
assertedAtis protected-effect commit time; and- structure, operation, and compliance actions have fixed
StructureEvent,InterventionEvent, andGovernanceEventmappings.
The current candidate now says the opposite on both points. The summary and review-request bullets should be updated before steward approval so the PR surface does not ask reviewers to approve semantics that are no longer present.
Drift and over-design assessment
The prior event-classification drift is closed. Event Grammar and Event Ingress retain ownership of primary-family classification.
No broad new scope drift. The changes remain within AssertionRecord submission semantics:
- assertion-act provenance;
- subject-time meaning;
- correction lineage;
- optional compatibility with an independently governed semantic event;
- record commit classification.
They do not alter authorization, approval, transaction coordination, review, promotion, current-state materialization, transport, retention, database authority, or OFARM2 runtime code.
No material over-design. The event-association section is detailed, but it validates AssertionRecord-specific compatibility rather than recreating Event Ingress classification. The temporal profiles are a closed set of nine rows rather than a general expression language. The correction change is one immutable lineage edge rather than a correction workflow.
At machine-materialization time, VERIFIED_OFFLINE_SUBMISSION must bind a real content-addressed assertion-time trust policy and a closed admission result; a mutable label or implementation-local notion of “verified” would not be sufficient. The candidate already places that work in the separately governed evidence-materialization stage, so this is not an additional Phase A blocker.
Final assessment
- Event-family ownership: closed
- Assertion time versus commit time: closed
- Branch-specific subject-time profiles: closed
- One-anchor narrowing disclosure: closed
- Correction lineage presence and non-mutation posture: closed
- Correction-target compatibility: must fix
- Scope drift: none remaining
- Architectural over-design: none
- Phase A disposition: not yet ready for steward semantic approval
Keep PR #23 in draft and do not approve section 17 until the correction-target predicate and stale PR description are repaired at an exact new head.
|
Re-review requested at exact head This revision closes the one remaining correction-target blocker:
The correction check consumes existing authorization-view and immutable prior-creation facts only as integrity inputs. It grants no authority over the prior record and changes no authorization, transaction, evidence, review, or current-state contract. The PR description is also updated: it no longer says Validation at this head:
Scope remains one non-authoritative AssertionRecord candidate file. Please re-review this exact head for Phase A semantic approval. |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
Re-review disposition: No blocking findings
Reviewed PR #23 at current head 9ac66f6ed5e316880c75a52cbe2e762ea59d06a5 against the previously reviewed head 97c9a985767a32bbe4722b472d83ff66f0b5086f.
The delta is one commit modifying only the existing non-authoritative candidate document: 40 additions and 18 deletions. PR #23 remains open, draft, mergeable, and limited to one changed file. Its description now reflects the current design rather than the superseded event-family and commit-time positions.
Previous remaining blocker: closed
The correction relation now has an executable, fail-closed target-compatibility predicate.
A CORRECTION requires exactly one immutable /supersedesAssertionRecordBinding, while INITIAL requires its absence. The document also removes the earlier pointer ambiguity:
/assertionBody/assertionPostureis the absolute effect-intent/result pointer;/assertionPostureis explicitly body-schema-relative notation;/supersedesAssertionRecordBindingis a separate absolute top-level pointer.
That prevents a future schema author from creating two posture fields or locating the lineage binding inside an implementation-defined body structure.
Exact correction-target closure
Every correction target must now satisfy all of these conditions:
- Prior existence and distinct identity: the exact prior record must already be committed and included in the authoritative transaction-start snapshot and history watermark. Self-reference, a future record, a concurrent record not visible in that snapshot, a merely prospective record, or timestamp-only existence evidence fails.
- Same assertion subtype: the old and new records must have exactly the same
assertionType. - Same governance boundary: immutable evidence must establish the same typed tenant or deployment boundary and the same applicable twin.
- Same authority anchor: a prior v0.2 record requires exact anchor kind, logical reference, and immutable selector equality. A prior v0.1 record requires direct kind/reference membership in its recorded anchors, without ancestry, alias, or inferred-equivalence matching.
- Same logical subject:
subjectTypeandsubjectRefmust match. The subject revision may differ, but correction cannot silently move the claim to another logical subject. - Lineage-only effect: the edge records that the new assertion corrects the prior assertion. It does not alter the prior claim state, review state, acceptance, in-force posture, or current-state contribution.
This closes the concrete exploit identified in the previous review: an actor authorized in one context can no longer attach a correction edge to an unrelated assertion from another subtype, subject, anchor, tenant, deployment, or twin.
Historical-context evidence is handled correctly
The prior AssertionRecord is not allowed to self-attest its tenant, twin, or creation context.
For a v0.2 target created under this profile, resolution uses the exact governed-effect receipt, its effect-intent digest, and the rule-selected extracted governance view. A legacy v0.1 target requires equivalent immutable creation or ingress evidence binding the exact record digest, commit position, governance boundary, twin posture, and recorded anchors.
Missing legacy evidence fails closed. Current storage location, identifier naming conventions, inferred scope ancestry, or caller-provided tenant and twin labels cannot repair the missing proof. This may make some legacy v0.1 records ineligible as correction targets, but it is an explicit compatibility restriction rather than silent reconstruction of facts that the old record did not carry.
Mapping, postcondition, and trace integration
The predicate is not isolated prose. It is integrated into the executable contract surface:
AR_CORRECTION_LINEAGEcopies the exact binding and requires every section 5.5 condition to pass.PC_CORRECTION_LINEAGEcovers prior existence, subtype, governance boundary and twin, anchor, subject, and non-mutation.PC_INPUTS_IMMUTABLEnow includes the prior assertion and its creation or ingress evidence.- The validation trace records the prior record digest, creation-evidence digest, history position, transaction-start snapshot and watermark, governance context, and each compatibility comparison.
- The migration section explicitly refuses to reconstruct missing legacy context from current state.
- The approval card exposes the same-context predicate as a steward decision rather than burying it in implementation guidance.
The hostile cases now cover:
- missing correction binding;
- wrong digest or record family;
- cross-subtype correction;
- cross-boundary or cross-twin correction;
- incompatible anchors;
- different logical subjects;
- self-reference;
- future or concurrent targets;
- lineage on an
INITIALassertion; and - treating lineage as acceptance, deletion, deactivation, or current-state replacement.
That coverage tests the observable domain outcomes rather than merely testing a helper function.
Previous closures remain intact
The latest patch does not regress the earlier corrections:
- Assertion subtype still does not derive primary event family.
- Optional semantic-event classification remains owned by Event Ingress and appears only in the trace.
assertedAtremains governed assertion-act time rather thaneffectCommittedAt.- Online and verified-offline assertion-act postures remain separate.
- The nine branch-specific
subjectTimeprofiles remain closed. - The one-anchor change remains explicitly identified as a narrowing with a lossless-representation stop condition.
- Every new assertion remains
PENDING_REVIEW. - Reporter authority remains separate from alleged performer identity and authority.
- Correction remains a new immutable assertion, not an update operation.
ASSERT_OPERATION_CLAIMremains non-executable until the separately ownedNOT_REQUIREDatomic transaction profile is closed.
Drift and over-design assessment
No scope drift. The correction predicate remains inside AssertionRecord domain semantics. It consumes authorization and transaction evidence as immutable inputs but does not:
- add a second authorization target;
- grant authority over the prior assertion;
- alter PR #11 path eligibility;
- change PR #20 transaction semantics;
- create a review or supersession effect;
- mutate prior history;
- introduce current-state behavior.
No new over-design. The patch adds one six-condition compatibility predicate using records and evidence already required by the architecture. It does not introduce a correction workflow, graph-reasoning service, lineage engine, generic relationship language, or mutable context registry.
The strict rule that subtype, governance boundary, twin, anchor, and logical subject must remain the same is deliberately narrow. Broader corrections must enter as a new INITIAL assertion or wait for a separately reviewed correction-relation profile. That is safer than giving body-schema authors an implicit widening mechanism.
At machine materialization, the verified-offline assertion-act evidence projection should explicitly include /supersedesAssertionRecordBinding whenever the posture is CORRECTION, so an importer cannot attach a different lineage target after the recorded assertion act. This follows from the candidate’s existing requirement that offline evidence bind the exact assertion content; it does not require another Phase A architecture amendment.
Both current-head GitHub workflows—repository validation and generated-currentness validation—completed successfully.
Final assessment
- Previous correction-target blocker: closed
- Absolute pointer ownership: closed
- Prior-existence and non-self rule: closed
- Same-subtype rule: closed
- Governance-boundary and twin rule: closed
- Authority-anchor rule: closed
- Logical-subject rule: closed
- Legacy compatibility posture: explicit and fail-closed
- PR-description metadata: corrected
- New semantic blockers: none
- Scope drift: none
- Architectural over-design: none
- Phase A disposition: ready for exact-head steward semantic approval
Approval should apply specifically to 9ac66f6ed5e316880c75a52cbe2e762ea59d06a5. It would approve only this non-authoritative candidate and its section 17 decisions. It would not merge the PR, accept active RFC law, create or promote schemas, change current/default status, close the missing NOT_REQUIRED transaction profile, or authorize OFARM2 runtime implementation.
Review at |
|
Exact-head re-review requested for The latest deep-verification findings are addressed:
Validation at this exact head:
Scope remains one non-authoritative Phase A candidate file inside the AssertionRecord submission semantics and commit classification trust boundary. No authorization, transaction, Event Ingress, review, schema, runtime, currentness, or OFARM2 boundary changed. Please re-review this exact head for steward semantic approval. |
samovers
left a comment
samovers
left a comment
There was a problem hiding this comment.
Re-review disposition: Request one bounded change
Reviewed PR #23 at exact head e8402eb9eb3e98aaa56149854e02c4b38e7a0364 against the previously reviewed head 9ac66f6ed5e316880c75a52cbe2e762ea59d06a5.
The delta is one commit modifying only the existing non-authoritative candidate document: 34 additions and 24 deletions. PR #23 remains open, draft, mergeable, and limited to one changed file. The PR description now accurately reflects the current transaction-snapshot, commit-class, semantic-event, temporal, and correction-lineage positions.
Source-verification findings
1. Fixture inventory: closed
Section 4.2 now reports the repository examples correctly:
- ten AssertionRecord examples;
- seven with
provenanceRefs; - exactly one with
executionRecordPayloadRefs; - three multi-anchor examples, including the in-scope compliance assertion with
LOTandFIELDanchors; - the delayed-sync operation claim correctly identified as a separate single-anchor example without an execution-payload reference.
This repairs the factual basis supporting the one-anchor narrowing and ensures the later conformance work includes both operation and compliance multi-context cases.
2. Unsupported canonical-history-position input: closed
The correction predicate no longer assumes a separate canonical-history position or general history watermark.
It now requires the prior assertion to resolve as an already committed positive record inside the immutable transaction-start snapshot identified by:
- trusted
transactionSnapshotRef; and - the corresponding snapshot digest.
A future, concurrent, unresolved, prospective, self-referential, or timestamp-only target fails. Immutable creation or ingress evidence continues to prove the prior record’s governance context, but no longer pretends to provide an additional ordering watermark.
This is consistent with PR #20, whose trusted finalization inputs explicitly include transactionSnapshotRef and its snapshot digest or equivalent immutable proof. The AssertionRecord contract is therefore consuming an existing transaction input rather than extending the transaction contract locally.
The trace and steward card were updated consistently: they now bind positive prior-record resolution in the trusted snapshot and explicitly state that no separate history-position or general-watermark input is assumed.
3. Commit-class terminology: closed
The candidate now distinguishes:
| Semantic level | Values |
|---|---|
| Constitutional commit-class labels | structure assertion, operation claim, compliance assertion |
| Current Event Ingress serialization tokens | STRUCTURE_ASSERTION, OPERATION_CLAIM, COMPLIANCE_ASSERTION |
That is the correct separation. The Event Grammar defines the lowercase semantic classes, while the current CommitIngress schema serializes them using uppercase enum tokens. The candidate now binds both without treating the transport/schema spelling as the constitutional concept itself.
This also removes the earlier ambiguity in which STRUCTURE_ASSERTION appeared to be simultaneously the authorization effect-subject kind, AssertionRecord subtype, and constitutional commit class.
4. Semantic-event association pointers and family precedence: closed
The optional event-association rule now identifies exact fields:
- assertion
/subject/subjectRefagainst envelope/subjectRefs; - assertion
/anchorScopes/0/scopeTypeand/anchorScopes/0/scopeRefagainst an entry in envelope/anchorScopes; - envelope
/primaryEventFamilyagainst the authoritative Event Ingress classification; - exact time selectors under
/timeSemantics.
The Event Ingress classification is authoritative and must equal the envelope’s stored /primaryEventFamily. A divergence fails Event Ingress rather than creating a local choice inside the AssertionRecord contract. The trace records the envelope and classification values, equality disposition, subject/scope match information, time comparisons, and applicable relationship proofs.
Those pointers correspond to actual required fields in the current SemanticEventEnvelope v0.1 schema.
Remaining blocker — duplicate direct matches have no deterministic index rule
The current SemanticEventEnvelope schema allows duplicate array entries:
/subjectRefshasminItems, but no uniqueness constraint;/anchorScopeshasminItems, but no uniqueness constraint.
The revised contract now requires the validation trace to record matched /subjectRefs and /anchorScopes indices. It also says that the matched envelope anchor index is recorded. It does not specify which index is selected when the same value occurs more than once.
For example, this envelope is schema-valid:
{
"subjectRefs": [
"operation:field-17:spray-1",
"operation:field-17:spray-1"
],
"anchorScopes": [
{
"scopeType": "FIELD",
"scopeRef": "field:17"
},
{
"scopeType": "FIELD",
"scopeRef": "field:17"
}
]
}Both index 0 and index 1 satisfy each direct-membership test. One implementation could record index 0; another could record index 1. They would:
- consume the same envelope bytes and digest;
- reach the same semantic pass/fail result;
- but produce different immutable validation-trace bytes and trace digests.
That violates the candidate’s deterministic, content-addressed trace posture. The issue is not whether duplicate entries should be encouraged. The issue is that they are currently schema-valid and therefore the matching projection needs an exact rule.
Smallest required patch
Add one local tie-break rule to section 7.3:
For direct subject or anchor membership, the matched index is the lowest zero-based array index whose value satisfies the exact comparison.
Also state:
- when direct subject membership succeeds, record that lowest
/subjectRefsindex; - when direct anchor membership succeeds, record that lowest
/anchorScopesindex; - when a relationship-proof path is used instead of direct subject membership, the direct-match index is absent and the exact immutable proof binding is recorded;
- duplicate identical entries do not create additional semantic effects;
- the full envelope digest continues to bind every duplicate entry.
Add one hostile case:
A schema-valid envelope contains duplicate exact subject and/or anchor entries.
Required result:
every conforming implementation selects the same lowest zero-based index
and produces the same validation-trace bytes and digest
An alternative deterministic rule—recording every matching index in ascending order—would also work, but the lowest-index rule is the smaller patch.
Do not amend SemanticEventEnvelope v0.1, introduce uniqueItems, redesign Event Ingress, or add a generic matching framework. This is one contract-local projection rule.
Previous semantic closures remain intact
The latest commit does not regress the previously approved substance:
- Assertion subtype does not derive primary event family.
- Event classification remains owned by Event Ingress.
assertedAtremains governed assertion-act time rather thaneffectCommittedAt.- Online and verified-offline assertion-act postures remain separate.
- The nine branch-specific
subjectTimeprofiles remain closed. - The one-anchor change remains an explicit narrowing with a lossless-representation stop condition.
- Correction targets remain restricted to an already committed, distinct assertion with the same subtype, governance boundary, twin, authority anchor, and logical subject.
- Correction lineage remains claim lineage only and does not mutate or deactivate the prior record.
- Every submitted assertion remains
PENDING_REVIEW. - Reporter authority remains separate from alleged performer identity and authority.
ASSERT_OPERATION_CLAIMremains blocked on the separately governedNOT_REQUIREDatomic transaction profile.
Drift and over-design assessment
No material scope drift. The latest commit corrects factual inventory, removes an unsupported transaction input, separates semantic labels from machine tokens, and makes existing event-association comparisons exact. It does not change authorization, transaction coordination, Event Ingress classification, review, promotion, current-state materialization, transport, retention, database authority, or OFARM2 runtime code.
No new architectural over-design. The remaining requested change is a one-sentence deterministic tie-break plus one hostile case. It adds no new schema family, event model, matching service, uniqueness rule, workflow layer, or mutable registry.
All four current-head GitHub checks completed successfully: two generated-currentness checks and two repository-validation checks. These prove repository hygiene, not the missing semantic tie-break.
Final assessment
- Fixture inventory corrections: closed
- Transaction-snapshot dependency: closed
- Commit-class semantic label versus machine token: closed
- Event-family authority and exact pointers: closed
- Previous correction-target predicate: preserved
- Duplicate direct-match index determinism: must fix
- Scope drift: none
- Architectural over-design: none
- Phase A disposition: not yet ready for exact-head steward approval
Keep PR #23 in draft and do not approve section 17 until the direct-match index tie-break is closed at an exact new head. After that bounded correction, no other semantic blocker is presently identified.
|
Exact-head re-review requested for The remaining deterministic-projection blocker is closed with one bounded candidate-file correction:
Validation at this exact head:
Scope remains one non-authoritative Phase A candidate file inside the AssertionRecord submission semantics and commit classification trust boundary. No Event Ingress schema, authorization, transaction, review, runtime, currentness, or OFARM2 boundary changed. Please re-review this exact head for steward semantic approval. |
Re-review at
|
Steward semantic approval — grantedI explicitly grant Phase A semantic approval for the AssertionRecord submission protected-effect contract candidate at commit This approval accepts the complete candidate and its section 17 approval-card decisions at that exact head, including:
The approved primary trust boundary is AssertionRecord submission semantics and commit classification. PR #23 stayed within that boundary as a one-file, draft, non-authoritative Phase A candidate. Authorization law remains governed by exact approved PR #11 head This decision does not:
The review's non-blocking anchor-comparison observation is understood as follows: direct anchor equality is deliberately stricter than subject association because the sole anchor is the authority-bearing element. This records the rationale for the approved behavior; it adds no relationship-proof fallback and does not amend the candidate. Any later semantic change to PR #23 requires renewed exact-head review and approval. PR #23 remains draft as the durable candidate and approval record. What is next: preserve this exact approved candidate while selecting the next separately governed issue. |
1 participant
Summary
AssertionRecordprotected-effect boundaryASSERT_STRUCTURE,ASSERT_OPERATION_CLAIM, andASSERT_COMPLIANCEPENDING_REVIEWsubjectTimeprofiles rather than deferring temporal meaning to later schema authorsAssertionRecord, using deterministic lowest-index direct-match projectionNOT_REQUIREDatomic transaction profile for operation-claim submission without editing that separate boundaryTrust boundary
Primary trust boundary: AssertionRecord submission semantics and commit classification.
This PR stays inside that boundary. It adds and revises one historical Phase A candidate only. It does not change authorization law, schemas, Event Grammar or Event Ingress classification, transaction machinery, review or promotion semantics, accepted RFCs, current/default indexes, OFARM2, or runtime code.
The correction-target predicate consumes the already selected authorization view, positive visibility in the trusted transaction-start snapshot identified by
transactionSnapshotRefplus its snapshot digest, and immutable prior-creation evidence as integrity inputs. It assumes no separate canonical-history position or general history watermark, grants no authority over the prior assertion, and does not redefine authorization, transaction, or evidence contracts.Dependency pins
03a21f669ee04f96d444e14f00ae7212cab0480398f8c4fafbae42c8f7fd931f43f53adcb4733713PR #20 covers the fresh-approval mode selected by structure and compliance assertions. It deliberately does not cover the
NOT_REQUIREDmode selected by operation claims, so the candidate records a separate downstream prerequisite instead of borrowing or inventing transaction semantics here.Review requested
Please review the explicit approval card, especially:
PENDING_REVIEWresult posture;assertedByPartyRefas the selected authority subject;assertedAtas governed assertion-act time, never protected-effect commit time;subjectTimeprofiles;NARROWINGwith lossless typed context and relationship proofs;NOT_REQUIREDtransaction-mode prerequisite.Validation
git diff --checkpython3 package_meta/tools/run_repository_validation_suite.pyAll pass at exact head
622376e2998cf8b3954ca19e81d2cce6fd57e5fe.Closes #22