Member Junction
    Preparing search index...

    Interface ScopeSecondaryDimension

    One declared dimension of a scope's Search Context.

    interface ScopeSecondaryDimension {
        acknowledgeCascadingOnBoundary?: boolean;
        advisory?: boolean;
        defaultValue?: SecondaryScopeValue;
        description?: string;
        enumValues?: string[];
        expansionQueryID?: string;
        inheritanceMode?: "cascading" | "strict";
        name: string;
        narrowingOf?: string;
        required?: boolean;
        restricts?: boolean;
        supersededByRules?: ScopeSupersessionRule[];
        trust?: ScopeDimensionTrust;
        valueDomain?: ScopeDimensionValueDomain;
        valueType?: ScopeDimensionValueType;
    }
    Index

    Properties

    acknowledgeCascadingOnBoundary? advisory? defaultValue? description? enumValues? expansionQueryID? inheritanceMode? name narrowingOf? required? restricts? supersededByRules? trust? valueDomain? valueType?

    Properties

    acknowledgeCascadingOnBoundary?: boolean

    Required acknowledgment when a RESTRICTING dimension declares inheritanceMode: 'cascading'.

    cascading means "content that lacks this dimension applies to everyone" — permissive, and therefore the wrong posture for a boundary. It is occasionally what an author genuinely wants (untagged legacy content that should stay visible while it is being backfilled), so it is not forbidden — but it must be deliberate rather than a default someone inherited, and it must be greppable. Setting this to true is that acknowledgment; without it the scope refuses to load.

    advisory?: boolean

    Marks this dimension as advisory (§5.12 supersession): it may only ever cause content to be REMOVED from an already-entitled set, never added.

    The consequence is a deliberately inverted failure posture. A boundary fails CLOSED — if it cannot be resolved the search is refused. An advisory dimension fails SOFT — if it cannot be resolved it is simply dropped and the search proceeds, because the worst case is that a superseded corpus stays in the results. Getting a boundary wrong leaks data; getting this wrong makes relevance worse.

    advisory and restricts are mutually exclusive; declaring both is a contradiction and is rejected at load.

    defaultValue?: SecondaryScopeValue
    description?: string
    enumValues?: string[]

    Required when valueType === 'enum'.

    expansionQueryID?: string

    MJ: Queries row that derives this dimension's value. Run as the acting user, so its MJ: Query Permissions gate the derivation. Bound parameters: PrimaryScopeRecordID, UserID, AgentID.

    inheritanceMode?: "cascading" | "strict"
    name: string

    Key as it appears in SearchContext.SecondaryScopes.

    narrowingOf?: string

    Names a ServerDerived dimension this one may only narrow (never widen).

    required?: boolean
    restricts?: boolean

    True when this dimension participates in the ACCESS BOUND. Acts as a profile: implies trust: 'ServerDerived', fail-closed resolution, and forbids freetext.

    supersededByRules?: ScopeSupersessionRule[]

    Ordered supersession rules — first match wins. Only meaningful on an advisory dimension.

    This is where "invoking skill A+B adds C and removes B" lives. The ordered logic derives a KEY from whichever dimension combination is active; the scope's filter then excludes whatever that key maps to, via a guarded AND NOT EXISTS (…) clause. The rules stay data rather than code, and because the clause can only subtract from an already-bounded set, a wrong rule degrades relevance instead of granting access — which is exactly why this needs none of the grammar, positive-assertion or fail-closed machinery a boundary requires.

    trust?: ScopeDimensionTrust
    valueDomain?: ScopeDimensionValueDomain
    valueType?: ScopeDimensionValueType

    Settings

    Member Visibility

    On This Page

    Properties