PROPOSED: Identity email probe registry + side-effect policy [AWAITING OPERATOR APPROVAL] #131

New issue

Open

opened 2026-08-29 10:28:27 +00:00 by nsaspy · 0 comments

nsaspy commented

2026-08-29 10:28:27 +00:00

Owner

State

AWAITING_OPERATOR_IMPLEMENTATION_APPROVAL

This is the first bounded implementation proposal derived from Auto-Research #180 and design #181. It does not authorize implementation and must not enter the executable RAGE queue until the operator explicitly approves it.

Priority / dependency role

Priority class: unlabelled dependency-unblocking Identity foundation.
Design authority: lost-rob0t/starintel-auto-research#181.
Research authority: lost-rob0t/starintel-auto-research#180.
Related Identity registry design: lost-rob0t/starintel-auto-research#173.
This slice is schema/normalization/policy only and does not require live #171/#172 network/orchestration implementation.

Bounded scope

Extend the planned/common Identity Platform Probe Registry model so email probes can be represented safely without creating an email-specific registry or executing provider traffic.

Required fields/semantics:

identifierType=email;
provider/site canonical identity;
source registry/source-definition identity + version/digest/lineage;
closed request/classification strategy or versioned StarLang source-definition ref;
explicit positive evidence predicate;
explicit negative evidence predicate;
capability requirements;
sideEffectClass = readOnly | mayNotifyTarget | mayMutateRemoteState | unknown;
provider/probe enabled/health metadata compatible with #173;
no executable function/callback fields;
no raw credential/session/token literals.

Default policy permits only readOnly probes. Other side-effect classes are denied unless a later explicitly authorized policy grants that exact effect.

Non-goals

no live provider HTTP requests;
no Holehe subprocess/library dependency;
no GHunt dependency;
no Google session/auth work;
no bounded fan-out execution yet;
no new StarLang email syntax;
no canonical ingest mutation;
no automatic identity merging.

Mandatory RED-first gate

Before any production mutation, add the smallest valid deterministic email probe-registry fixture requiring:

identifierType = email
source/version/digest/lineage
provider identity
closed strategy/source-definition ref
explicit positive condition
explicit negative condition
sideEffectClass = readOnly

Run it against untouched current master and record RED because no normalized Identity email-probe registry/schema exists.

Negative RED fixtures must require rejection of:

unknown/missing side-effect class;
arbitrary Lisp/Python callback/function field;
raw cookie/token/credential literal;
missing source lineage/version identity;
a side-effecting probe treated as executable under default policy;
conflicting duplicate canonical probe semantics without an explicit conflict result.

A malformed fixture or broken environment does not count as RED.

Acceptance

valid email probe definitions normalize deterministically;
email reuses the common Platform Probe Registry rather than creating a separate registry;
positive/negative predicates remain distinct from transport/block/error state;
default policy allows only readOnly probes;
mayNotifyTarget, mayMutateRemoteState and unknown are fail-closed by default;
registry data cannot name executable host callbacks;
raw credentials/sessions/tokens are rejected;
source/version/digest/lineage survive normalized representation;
deterministic duplicate/conflict handling preserves lineage;
no product network I/O occurs in this slice;
repository-native full deterministic local gate is green on exact implementation head.

Follow-on dependency order

After separate operator approval and completion of this slice, design #181 proposes:

identity.enrichEmail typed request/result contract;
bounded execution using #171/#172;
defensive Google public-profile provider normalization;
canonical ingest integration;
optional real Google adapter only if separately justified.

Implementation approval

PENDING / AWAITING_OPERATOR_IMPLEMENTATION_APPROVAL

Only explicit operator approval may move this issue into RAGE.

## State `AWAITING_OPERATOR_IMPLEMENTATION_APPROVAL` This is the first bounded implementation proposal derived from Auto-Research #180 and design #181. It does **not** authorize implementation and must not enter the executable RAGE queue until the operator explicitly approves it. ## Priority / dependency role - Priority class: unlabelled dependency-unblocking Identity foundation. - Design authority: `lost-rob0t/starintel-auto-research#181`. - Research authority: `lost-rob0t/starintel-auto-research#180`. - Related Identity registry design: `lost-rob0t/starintel-auto-research#173`. - This slice is schema/normalization/policy only and does not require live #171/#172 network/orchestration implementation. ## Bounded scope Extend the planned/common Identity Platform Probe Registry model so email probes can be represented safely without creating an email-specific registry or executing provider traffic. Required fields/semantics: - `identifierType=email`; - provider/site canonical identity; - source registry/source-definition identity + version/digest/lineage; - closed request/classification strategy or versioned StarLang source-definition ref; - explicit positive evidence predicate; - explicit negative evidence predicate; - capability requirements; - `sideEffectClass = readOnly | mayNotifyTarget | mayMutateRemoteState | unknown`; - provider/probe enabled/health metadata compatible with #173; - no executable function/callback fields; - no raw credential/session/token literals. Default policy permits only `readOnly` probes. Other side-effect classes are denied unless a later explicitly authorized policy grants that exact effect. ## Non-goals - no live provider HTTP requests; - no Holehe subprocess/library dependency; - no GHunt dependency; - no Google session/auth work; - no bounded fan-out execution yet; - no new StarLang email syntax; - no canonical ingest mutation; - no automatic identity merging. ## Mandatory RED-first gate Before any production mutation, add the smallest valid deterministic email probe-registry fixture requiring: ```text identifierType = email source/version/digest/lineage provider identity closed strategy/source-definition ref explicit positive condition explicit negative condition sideEffectClass = readOnly ``` Run it against untouched current `master` and record RED because no normalized Identity email-probe registry/schema exists. Negative RED fixtures must require rejection of: - unknown/missing side-effect class; - arbitrary Lisp/Python callback/function field; - raw cookie/token/credential literal; - missing source lineage/version identity; - a side-effecting probe treated as executable under default policy; - conflicting duplicate canonical probe semantics without an explicit conflict result. A malformed fixture or broken environment does not count as RED. ## Acceptance - valid email probe definitions normalize deterministically; - email reuses the common Platform Probe Registry rather than creating a separate registry; - positive/negative predicates remain distinct from transport/block/error state; - default policy allows only `readOnly` probes; - `mayNotifyTarget`, `mayMutateRemoteState` and `unknown` are fail-closed by default; - registry data cannot name executable host callbacks; - raw credentials/sessions/tokens are rejected; - source/version/digest/lineage survive normalized representation; - deterministic duplicate/conflict handling preserves lineage; - no product network I/O occurs in this slice; - repository-native full deterministic local gate is green on exact implementation head. ## Follow-on dependency order After separate operator approval and completion of this slice, design #181 proposes: 1. `identity.enrichEmail` typed request/result contract; 2. bounded execution using #171/#172; 3. defensive Google public-profile provider normalization; 4. canonical ingest integration; 5. optional real Google adapter only if separately justified. ## Implementation approval `PENDING / AWAITING_OPERATOR_IMPLEMENTATION_APPROVAL` Only explicit operator approval may move this issue into RAGE.