Skip to content

Prompt Specification Standard

Ciprian-LocalPulse edited this page Jul 31, 2026 · 1 revision

Prompt Specification Standard

Cross-cutting reference. Governs every LLM-facing prompt used by Cortex Scoring Model, Persona Mirror Drafting, and Negotiation Intelligence Algorithms.

No Secret "God Prompt"

Sentinel does not use a single hidden master prompt that encodes undocumented behavior. Every prompt used anywhere in the system is a versioned, reviewable artifact living in prompts/, with its inputs, outputs, and constraints specified in the open — the same transparency principle applied to scoring in Design Philosophy applies to the prompts themselves. An operator (or contributor) should be able to read exactly what instruction produced a given output.

Prompt Specification Format

flowchart TD
    A[Prompt Spec File] --> B[Metadata: id, version, owner component]
    A --> C[Purpose statement]
    A --> D[Input contract: required schema fields]
    A --> E[Constraints: hard rules, e.g. no fabricated facts]
    A --> F[Template body]
    A --> G[Output contract: expected schema]
    A --> H[Test cases: input/expected-output pairs]
Loading

Each prompt specification is a structured document, not a loose string, containing:

Section Purpose
id / version Stable identifier and version, referenced by the calling component
owner_component Which pillar/module this prompt belongs to
purpose One or two sentences: what this prompt is for
input_contract Which schema fields (from Data Schemas Reference) are required inputs
constraints Hard rules the model must follow — see below
template The actual prompt template, with clearly marked variable-substitution points
output_contract Expected output shape, validated after generation
test_cases Input/output pairs used to regression-test the prompt when it's updated

Universal Constraints

Every prompt specification in the system, regardless of which component owns it, inherits a base set of constraints derived from Design Philosophy:

  1. No fabricated facts. The model must not state as true anything not present in, or directly derivable from, the input data.
  2. No manufactured urgency or scarcity unless traceable to real evidence in the input contract.
  3. No impersonation beyond the founder's own consented style profile. Voice-matching applies only to the founder's own drafted messages, never to generating content that claims to be from — or mimics — anyone else.
  4. Explainability preserved. Where the prompt produces a score or recommendation, the output contract requires contributing factors, not a bare number.
flowchart LR
    A[Any Prompt Specification] --> B[Base Constraint: No fabricated facts]
    A --> C[Base Constraint: No manufactured urgency]
    A --> D[Base Constraint: Consented voice only]
    A --> E[Base Constraint: Explainable output]
    B --> F[Component-specific constraints layered on top]
    C --> F
    D --> F
    E --> F
Loading

Versioning and Change Review

A change to a prompt template requires a version bump and passing the associated test cases before the new version can be activated. This mirrors the Persona Stylometry Engine profile-versioning approach: prompts, like style profiles, are allowed to evolve, but never silently.

sequenceDiagram
    participant Dev as Contributor
    participant Repo as prompts/ directory
    participant Test as Test Suite
    participant Sys as Runtime System

    Dev->>Repo: propose new prompt version
    Repo->>Test: run test_cases against new version
    Test-->>Dev: pass / fail results
    alt all tests pass
        Dev->>Repo: merge new version
        Repo->>Sys: new version available for activation
    else tests fail
        Dev->>Dev: revise template
    end
Loading

Example: Structure of a Scoring Prompt Spec (Illustrative)

id: cortex_urgency_scoring
version: 3
owner_component: cortex
purpose: >
  Extract urgency-contributing factors from a NormalizedMessage
  and produce a scored, explainable urgency assessment.
input_contract:
  - NormalizedMessage.body_clean
  - NormalizedMessage.explicit_priority
  - thread_history (bounded window)
constraints:
  - inherits: base_constraints
  - must_not: infer deadlines not stated or clearly implied in text
output_contract:
  schema: AnalysisResult.urgency
test_cases: prompts/tests/cortex_urgency_scoring.test.yaml

See Also

Clone this wiki locally