From f370f1bad931f46e7a2de442887bf70de5303a1d Mon Sep 17 00:00:00 2001 From: Dan Wolfson Date: Tue, 13 Oct 2026 21:15:58 -0500 Subject: [PATCH 1/2] docs(issues): ISSUE-150 - owner's review of the design requirements and Dr.Egeria gaps Requirements 1 and 2 accepted; the credential tier is an informational key, not a control (the engine host enforces it). New commands for process subtypes where needed; the executor-on-step link needs live testing; the engine side will likely need commands. Signed-off-by: Dan Wolfson --- PYEGERIA_ISSUES.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/PYEGERIA_ISSUES.md b/PYEGERIA_ISSUES.md index 53be9415..94c71327 100644 --- a/PYEGERIA_ISSUES.md +++ b/PYEGERIA_ISSUES.md @@ -247,10 +247,15 @@ into the entry now, so it isn't rediscovered from scratch later. 2. A process step needs its `GovernanceActionExecutor` link and its manifest `additionalProperties`. Check that `Link Action to Action Executor` accepts a `GovernanceActionProcessStep` (a subtype of `GovernanceActionType`) as its subject. It should, but this hasn't been live-verified (see the Action Author note in CLAUDE.md). 3. Declaring the engine side may need `SupportedGovernanceService` / governance-engine commands, if Dr.Egeria doesn't already have them. Check before building. -**Requirements proposed by RE's expansion-design session (2026-10-13; it found no contradiction with the direction; pending the owner's review):** +**Owner's answers on these gaps (2026-10-13):** +1. Process subtypes: create new Dr.Egeria commands for the other process types where needed. +2. Executor on a process step: yes, it needs live testing. +3. Engine-side commands: yes, likely needed. + +**Requirements proposed by RE's expansion-design session (2026-10-13; it found no contradiction with the direction). Owner's review, the same day: 1 and 2 accepted; 3 kept as an informational key only:** 1. **One declaration, idempotent.** The manifest's qualifiers must live on the `GovernanceActionType` itself (`supportedRequestParameters` or `additionalProperties`), so Egeria, the Portal and RE all read the same declaration. That means question ids, perspectives, `purpose` (from the existing `VALID_PURPOSES` set) and `family`. Declaring is idempotent by qualifiedName: declaring twice updates, and never creates a second type. Dr.Egeria's upsert (Create→Update by qualified name) already behaves this way. 2. **Label synchronous values differently from recorded ones.** On a screen, a value computed now must be labelled "computed now · not recorded", and a stored result "last recorded ". A reader must never mistake a synchronous draw for a governed measurement. (The envelope gives the state and `measured_at`; the "recorded or not" label is the caller's, from which path it used.) -3. **State the credential tier.** User-written steps stay on the resource's read-only tier (owner ruling, 2026-10-07). A `GovernanceActionType` declared for one must say so, with a property naming the tier (e.g. `credential_tier: read_only`). Otherwise Egeria would schedule it like any engine action. +3. **State the credential tier.** User-written steps stay on the resource's read-only tier (owner ruling, 2026-10-07). A `GovernanceActionType` declared for one must say so, with a property naming the tier (e.g. `credential_tier: read_only`). **Owner: an informational key, not a control.** Egeria schedules Engine Actions the same way regardless, and never hands a step its resource credentials. The engine host does: RE's wrapper enforces read-only from the step's manifest (`StepManifest.credential_tier`). The key on the declaration is for governance visibility (whoever reviews or approves the type can see it), and for any other engine host that might run the step later. --- From 44210e6f16815753d9c066ca4989da4ed14c9248 Mon Sep 17 00:00:00 2001 From: Dan Wolfson Date: Tue, 13 Oct 2026 21:18:29 -0500 Subject: [PATCH 2/2] docs(issues): ISSUE-150 - design session withdrew the credential-tier-as-control reading Signed-off-by: Dan Wolfson --- PYEGERIA_ISSUES.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/PYEGERIA_ISSUES.md b/PYEGERIA_ISSUES.md index 94c71327..e8fc0e10 100644 --- a/PYEGERIA_ISSUES.md +++ b/PYEGERIA_ISSUES.md @@ -255,7 +255,7 @@ into the entry now, so it isn't rediscovered from scratch later. **Requirements proposed by RE's expansion-design session (2026-10-13; it found no contradiction with the direction). Owner's review, the same day: 1 and 2 accepted; 3 kept as an informational key only:** 1. **One declaration, idempotent.** The manifest's qualifiers must live on the `GovernanceActionType` itself (`supportedRequestParameters` or `additionalProperties`), so Egeria, the Portal and RE all read the same declaration. That means question ids, perspectives, `purpose` (from the existing `VALID_PURPOSES` set) and `family`. Declaring is idempotent by qualifiedName: declaring twice updates, and never creates a second type. Dr.Egeria's upsert (Create→Update by qualified name) already behaves this way. 2. **Label synchronous values differently from recorded ones.** On a screen, a value computed now must be labelled "computed now · not recorded", and a stored result "last recorded ". A reader must never mistake a synchronous draw for a governed measurement. (The envelope gives the state and `measured_at`; the "recorded or not" label is the caller's, from which path it used.) -3. **State the credential tier.** User-written steps stay on the resource's read-only tier (owner ruling, 2026-10-07). A `GovernanceActionType` declared for one must say so, with a property naming the tier (e.g. `credential_tier: read_only`). **Owner: an informational key, not a control.** Egeria schedules Engine Actions the same way regardless, and never hands a step its resource credentials. The engine host does: RE's wrapper enforces read-only from the step's manifest (`StepManifest.credential_tier`). The key on the declaration is for governance visibility (whoever reviews or approves the type can see it), and for any other engine host that might run the step later. +3. **State the credential tier.** User-written steps stay on the resource's read-only tier (owner ruling, 2026-10-07). A `GovernanceActionType` declared for one must say so, with a property naming the tier (e.g. `credential_tier: read_only`). **Owner: an informational key, not a control.** Egeria schedules Engine Actions the same way regardless, and never hands a step its resource credentials. The engine host does: RE's wrapper enforces read-only from the step's manifest (`StepManifest.credential_tier`). The key on the declaration is for governance visibility (whoever reviews or approves the type can see it), and for any other engine host that might run the step later. The design session confirmed this when asked (2026-10-13). It withdrew its "control" reading: the only reader other than RE's wrapper would be a second engine host, which enforces the tier itself. An Egeria-side approval step or governance rule that reads the tier would be new design nobody has asked for. ---