feature - promote governed continuity/memory-operation kernels, draft RFC 013/014/015 - #33
Draft
dannymeijer wants to merge 16 commits into
Draft
dannymeijer wants to merge 16 commits into
dannymeijer wants to merge 16 commits into
Conversation
…kernels Promotes the sleep-demo spike's kernel work (governed_continuity.incn, governed_memory_operations.incn, the governed_profile* family, their tests, and the supporting identifiers.incn/lib.incn re-exports) from an uncommitted task-owned research checkout into a real, committed feature branch. This code has been the real evaluate_continuity/governed memory admission boundary behind the sleep learning demo's pacing work for the last several sessions (see GOVERNED_CONTINUITY_HYPERQUANT_SPIKE_DECISION.md at the customer-demo project root, dated 2026-07-24, and the hees-governed-demo-polish loop dated 2026-07-25, both of which deliberately left it uncommitted as a preserved task-owned baseline pending explicit authorization to commit). Also carries the incan.toml manifest fix (removing the redundant [project.scripts] library declaration that duplicate-registers src/lib.incn as an Executable target -- same fix as #31). Verified: `make test` -- 61/61 .incn tests pass, identical to the source checkout this was copied from. `make fmt` and the incan.lock-version part of `make boundary` fail identically on the untouched original baseline too (confirmed by running both there before touching anything) -- this is pre-existing toolchain-pinning drift, since only incan 0.5.0-rc2 is installed locally and this repo pins 0.5.0-dev.23. incan.lock here is regenerated under rc2, not the pinned dev.23; treat CI (or a dev.23 build) as the authoritative gate for both concerns. Next: stabilize the goal/temporal/memory-operation contracts through the RFC path (production-implementation-order item 1 in the decision record). governed_memory_operations.incn's own docstring already says it is "adjacent to RFC 003" and does not implement its retrieval ingress -- that gap is the subject of the follow-up RFC work in this same worktree.
…cle ops) Stabilizes the two kernel modules committed in ba4e24a through this repo's RFC process, per production-implementation-order item 1 in GOVERNED_CONTINUITY_HYPERQUANT_SPIKE_DECISION.md. Both documents are Draft, grounded directly in the already-tested implementation (not invented from scratch), and follow the existing RFC 003/000 header/section conventions. RFC 013 covers governed_continuity.incn: package-declared goal/schedule/ phase authority and the evaluate_continuity admission function. RFC 014 covers governed_memory_operations.incn as an INDEPENDENT lifecycle/ access-control contract (inspect/select_prompt/write/revoke/supersede against package-declared memory-class policy) -- deliberately not framed as part of RFC 003, which owns retrieval ingress/materialization. The source's own docstring already disclaims RFC 003 conformance; RFC 014 makes that relationship precise instead of leaving it as a one-line hedge, and flags the one real open composition question (does an RFC-003-accepted record still need a SelectPrompt admission under RFC 014, or is RFC 003 acceptance alone sufficient) rather than silently picking an answer. Neither RFC has a filed GitHub issue yet, matching this repo's process (dedicated proposal issue precedes RFC PR) -- both are left for review before anything is published. Not pushed; local commit only.
Investigated whether governed_profile* (7 modules, ~1870 lines, committed in ba4e24a) needs the same same-night RFC treatment as RFC 013/014. Concluded no: unlike continuity/memory-operations, this module family visibly generalizes pieces RFC 000/001/002/006 already own and looks closely related to the already-shipped console_profile_0_1 (RFC 010), raising a real superseding-vs-generalizing editorial question that this repo's RFC process reserves for discussion, not something to settle unilaterally overnight without having read those RFCs in full. Recorded the reasoning and a concrete next-step recommendation instead of producing a rushed, likely-inaccurate RFC. Not blocking -- the code is already committed and tested regardless of its RFC-track status.
…er research Revisits the governed_profile* scoping decision from b3455b3. Read RFC 000/001/002/006 in full and the complete governed_profile* source (all 7 modules, ~1870 lines) rather than skimming, and found the module family is narrower than it first looked: it delegates structural admission to the existing Hees 0.0.1 admit_model_proposal kernel and only implements the already-proven five-outcome-kind pattern (deliver/refuse/escalate, no repair, no RFC 004 constraint composability, no RFC 007/008 richness, one Content DNA state, one receipt kind) -- not a claim of implementing RFC 001/002/006's full elaborate designs. RFC 015 documents this honestly: every relationship section to RFC 000/001/002/006/010 names the real, specific deltas (missing source_digests, no no_answer state, single receipt kind vs RFC 006's four, no constraint-plan composability, etc.) rather than asserting conformance. The one real open editorial question from the earlier scoping note -- whether this eventually supersedes or stays independent of RFC 010's console_profile_0_1 -- is named explicitly as an open question rather than resolved unilaterally, since that's still genuinely Danny's call. Updated governed_profile_scoping_notes.md with a same-night addendum explaining the reversal, rather than silently replacing the original reasoning. Updated rfcs/README.md. Verified make test still 61/61. Not filed as a GitHub issue, not published -- same as RFC 013/014, this repo's process wants a discussed proposal issue before an RFC PR, and publication needs Danny's review first regardless.
Resolves conflicts against 5+ PRs that landed on origin/main independently while this branch's local worktree was on a stale snapshot (RFC 011/012 drafted, guided programme eligibility feature landed, the [project.scripts] incan.toml fix already merged via #31 -- same fix this branch also carried, auto-merged cleanly since both sides made the identical change). - rfcs/README.md: kept both RFC 011/012 (origin/main) and RFC 013/014/015 (this branch) in correct numeric order. - src/lib.incn: purely additive re-export conflict -- both the governed_* facade (this branch) and the new programme facade (origin/main) kept. - incan.lock: regenerated fresh via `incan lock` rather than hand-merging a lockfile. Verified: `incan oven bake` + `make test` -- 109/109 pass (up from 61, since the merge pulled in the guided-programme eligibility test suite).
…tent Uses "Hees.ai" consistently instead of bare "Hees" throughout the new governed_continuity/governed_memory_operations/governed_profile* module docstrings and RFC 013/014/015, matching this repo's product naming.
…ply incan fmt incan.lock had been regenerated against a locally-installed 0.5.0-rc2 build during earlier conflict-resolution work, tripping the boundary check's toolchain-pin assertion. Rebuilt the pinned 0.5.0-dev.23 compiler from source and regenerated the lock against it. Also applied `incan fmt` to five files this branch touches that had drifted from the formatter's canonical style (whitespace/wrapping only, no logic changes) -- confirmed via diff and by 109/109 tests still passing before and after.
Superseded by RFC 015 itself, which already states the real relationship deltas and the one open editorial question professionally. The removed file was written as in-session process narrative (timestamps, first-person reasoning, the maintainer addressed by name) rather than documentation, which doesn't belong in a public repo.
Reworded mentions of the private, unpublished 'customer-demo project' and its internal spike-decision document to generic, self-contained phrasing (a reference implementation / a reference caller), since neither is resolvable by a reader of this public repo. No technical content changed.
…in RFC 013/014/015 Addresses the P0/P1 findings from an independent review of this branch: - Package artifact_digest (and each memory atom's provenance_digest) was checked for syntax only, never recomputed against the package's own content -- a caller could mutate a package after its digest was stamped and still get a decision, receipt, or Content DNA under the stale identity. Added digest_continuity_package, digest_governed_memory_policy, digest_governed_profile_package, and digest_governed_memory_provenance; wired recompute-and-compare checks into all three validators. - A phase's declared maximum_seconds was validated at the package level but never enforced at proposal time -- Continue could keep a session in one phase past its maximum forever. Added a uniform maximum check across Continue/Transition/Close. - SessionContinuityState and GovernedMemoryRecord were plain caller-supplied models with nothing tying them to a real prior evaluate_continuity/write result -- a caller could hand-assemble plausible history and skip actual earlier admission. Added state_witness/record_witness self-consistency digests, stamped on output and re-verified before trusting a supplied prior state or existing record. Documented honestly in both RFCs: this is an unkeyed digest over public source, so it catches accidental corruption and hand-assembly, not a caller willing to reproduce the formula -- a real signed handle needs a keyed MAC, which Incan's stdlib doesn't yet provide (filed as incan#1075). - Two smaller fixes folded in: governed_profile_identity.incn's digest helpers now route through one documented, invariant-justified wrapper instead of bare unwrap() calls; RFC 015's guide example now matches the real exported API (artifact_revision/digest_id_type, correct bind_governed_request/ governed_proposal signatures). 19 new tests (109 -> 128), all passing against the pinned 0.5.0-dev.23 toolchain.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Process note: this repo's
AGENTS.mdsays new runtime capabilities and material public-contract changes should start as a dedicated RFC proposal issue before an implementation PR. This branch does not follow that -- it bundles a kernel promotion with three Draft RFCs in one place, opened as a draft for visibility/review, not as a claim that it's ready to merge as-is. The three proposal issues are now filed (see below), but the implementation still landed alongside the RFCs rather than after discussion. Happy to split it into separate PRs if that's the better path once you've had a look.What's in it:
governed_continuity.incn,governed_memory_operations.incn, and thegoverned_profile*family (7 modules) -- the actualevaluate_continuitykernel behind the sleep-learning demo's goal/schedule/session admission and memory lifecycle.governed_memory_operations.incnas independent of RFC 003 (lifecycle/access-control vs. RFC 003's retrieval ingress), matching the source's own docstring, and names the one real open composition question between them.governed_profile*family, after reading RFC 000/001/002/006 in full: every relationship section names its real, specific deltas from those RFCs (no repair path, no RFC 004 constraint composability, one Content DNA state instead of two, one receipt kind instead of four) rather than claiming conformance. Names one real open editorial question -- whether this eventually supersedes or stays independent of RFC 010'sconsole_profile_0_1-- rather than deciding it unilaterally.Required a merge with
mainto resolve conflicts from concurrent changes (RFC 011/012 drafted, the guided-programme eligibility feature shipped, and the[project.scripts]incan.tomlmanifest fix already merged via #31, which this branch also carried and merged cleanly since both sides made the identical change). RFC numbering (013/014/015) was rechecked againstmainafter the merge -- no collision with 011/012.Review response
An independent review of this branch found three P0 authority-boundary gaps and several P1s. All are now addressed:
artifact_digest(and each memory atom'sprovenance_digest) was checked for syntax only, never recomputed -- a caller could mutate a package after its digest was stamped and still get a decision, receipt, or Content DNA under the stale identity. Fixed in all three modules:digest_continuity_package,digest_governed_memory_policy,digest_governed_profile_package, anddigest_governed_memory_provenancenow recompute-and-compare, matching the pattern already used by the shippedconsole_profilesibling.maximum_secondswas validated at the package level but never enforced at proposal time --Continuecould keep a session in one phase past its maximum indefinitely. Fixed: a uniform maximum check now applies toContinue/Transition/Closealike.SessionContinuityStateandGovernedMemoryRecordwere plain caller-supplied models with nothing tying them to a real priorevaluate_continuity/write result -- a caller could hand-assemble plausible history and skip actual earlier admission. Fixed withstate_witness/record_witnessself-consistency digests, stamped on output and re-verified before trusting a supplied prior state or existing record. This is deliberately scoped honestly in both RFCs: it's an unkeyed digest over public source, so it catches accidental corruption and hand-assembly, not a caller willing to reproduce the formula. A real signed handle needs a keyed MAC, which Incan's standard library doesn't yet provide -- filed upstream as incan#1075 rather than hand-rolled here.governed_profile_identity.incnnow route through one documented, invariant-justified wrapper instead of bareunwrap()calls; RFC 015's guide example now matches the real exported API.19 new tests added (109 -> 128), including stale-digest mutation tests for action/evidence/memory/policy/guided-material/goal/schedule/memory-class changes, exact-boundary and first-out-of-range maximum tests, and forged-witness adversarial tests. All three RFCs' text was updated to describe the new checks precisely, including the honest scope limit on the witness fields.
Public API and boundary impact
Additive: new
governed_continuity,governed_memory_operations, andgoverned_profile*public modules and functions. Nothing existing is changed. No package content, client material, or credentials included.Verification
make test-- 128/128 pass, verified against the pinnedincan 0.5.0-dev.23toolchain (built from source to match this repo's own pin exactly, rather than a locally-installed newerrc2build that had been masking this with unrelated type errors).make fmt-- clean against the pinned toolchain.make boundary-- theincan.locktoolchain-pin check passes. Four remaining boundary errors (scripts/claude_hooks/dispatch.pyand.claude/skillsoutside the public allowlist) reproduce identically on an unmodifiedmaincheckout -- pre-existing from chore - commit Claude Code hooks + previously-local AGENTS.md/skills #32, unrelated to this branch.