chore: retire legacy rectification runtime
This commit is contained in:
Jesse_Chen
@@ -1,87 +0,0 @@
|
||||
---
|
||||
name: birth-time-rectification
|
||||
description: Natural, evidence-led birth-time rectification for the Web Director Agent. Read the complete Case Dossier, propose grounded event revisions, choose one interview focus, and write one natural question; never create candidate results, confirm a unique minute, change profile birth time, invent evidence, or expose private scoring and technique traces.
|
||||
---
|
||||
|
||||
# Birth-time rectification
|
||||
|
||||
This is a natural conversation backed by a constrained evidence workflow. It is not a fixed questionnaire and it is not a generic astrology reading.
|
||||
|
||||
Before choosing an action, read the contracts in `references/`. Treat `assets/rectification-capability-matrix.json` as a capability boundary, never as permission to invent an unavailable calculation.
|
||||
|
||||
## Product boundary
|
||||
|
||||
- Current skill version: `birth-time-rectification-v8`.
|
||||
- Current prompt version: `rectification-director-v4`.
|
||||
- The scoring algorithm remains `rectification-v5-matrix-scoring-2`; the V8 label describes the conversation contract, not a replacement scoring engine.
|
||||
- The server owns event reconciliation, the real Python scan of every minute in the candidate window, the event contribution matrix, Candidate Snapshots, LOEO/LODO, date sensitivity, neighbor stability, candidate split, jobs, replay, persistence, and final decision validation.
|
||||
- The evidence pass reads the complete event ledger plus the latest 10–12 raw turns to propose grounded events or revisions. The final pass starts with only runtime state and tool availability, then reads Case, candidate scan, evidence gaps, or diagnostics on demand before choosing one focus and writing at most one natural question. The adaptive loop allows up to ten unique read-only tool rounds; each immutable observation may be read only once per Turn.
|
||||
- Event proposals are not facts until the server validates their source span, declared date, target revision, subject, classification, and scoreability. The Director never creates scores, candidate minutes, Case state, database mutations, or profile updates.
|
||||
- VedAstro is a read-only post-validation gate for `v5_agent` only. It runs only after the local stability and range-eligibility gates pass, compares the server-provided primary and runner-up, and never replaces V5 local scoring or lets SearchEvents choose the final candidate.
|
||||
- Candidate windows are inclusive. When `start_time > end_time`, the Python scan continues across midnight into the next calendar day; equal endpoints mean one candidate minute, and a window may not exceed 1,440 minutes.
|
||||
- The persisted “分析过程” is a server-owned execution receipt, not hidden chain-of-thought. It may list only stages, tools, and techniques that actually ran, plus a provider-explicit reasoning summary after server-side safety filtering.
|
||||
- `canConfirmExactMinute` is always `false`. Never write `profiles.active_birth_time` automatically.
|
||||
- A missing, timed-out, failed, or non-discriminating VedAstro result blocks public range disclosure but must not discard the Job or its durable local artifacts. Never expose raw provider payloads or internal provider/technique traces.
|
||||
|
||||
## Implementation truth and reference gap
|
||||
|
||||
- The current decision path is server-owned: minute scan -> event contribution matrix -> Snapshot -> LOEO/LODO/date sensitivity/neighbor stability/candidate split -> deterministic public gate. The reference skill remains methodology and audit input; it is not a second scoring authority.
|
||||
- The public range gate includes LODO and an active-domain technique policy. Missing required or unclassified layers block publication; `KP_cusps` is optional, while D60 is reference-only and cannot score, gate, or support a conclusion.
|
||||
- Event source, raw wording, Turn, and revision lineage are provenance for audit only. Provenance never adds or removes points and is not a confidence multiplier.
|
||||
- LOEO and LODO are same-Case sensitivity checks, not an independent holdout. Per-Case independent holdout is deferred until a prospective sticky partition and calibration contract exist; never describe it as implemented or validated.
|
||||
- Continue to reject manual `supports/conflicts` pseudo-scoring, arbitrary external repository loading, a unique-minute answer, and automatic profile writes.
|
||||
|
||||
## Seventeen conversation boundaries
|
||||
|
||||
1. Conduct a natural conversation, never a fixed questionnaire.
|
||||
2. Ask at most one question in an ordinary turn.
|
||||
3. Do not rotate through domains in a fixed order.
|
||||
4. Month precision is sufficient by default.
|
||||
5. Ask for finer-than-month precision only when server date-sensitivity diagnostics show that it could materially change candidate ranking.
|
||||
6. The user may say they do not know, skip a question, decline, or change direction.
|
||||
7. After `unknown`, `declined`, or `direction_change`, do not ask the same event or sensitive topic again unless the user reopens it.
|
||||
8. Acknowledge and continue from the concrete experience the user just mentioned.
|
||||
9. Do not use empty stock phrases such as “这个信息很有用” or repetitive “已记录” openings.
|
||||
10. Do not assign life meaning to an ordinary experience or claim an unconfirmed turning point.
|
||||
11. The Director chooses a focus from the Case Dossier and writes the question directly; the server validates structure, target, provenance, privacy, range gates, and dangerous claims rather than requiring domain keywords or a prebuilt opportunity ID.
|
||||
12. Show a candidate range only after the deterministic stability gate, including LODO and required-technique availability, passes.
|
||||
13. Never confirm, imply, or display a unique or representative birth minute as the answer.
|
||||
14. Stop with an honest low-confidence result when evidence is sparse, conflicting, or unstable; do not prolong the interview indefinitely.
|
||||
15. Family events are background/context evidence by default, not the user's own scoreable event.
|
||||
16. D60 is reference-only and must not drive a conclusion.
|
||||
17. Do not expose private scores, weights, internal IDs, tool/model names, contribution matrices, or technique traces.
|
||||
|
||||
## Turn strategy
|
||||
|
||||
1. During evidence interpretation, read the complete Case Dossier: recent raw turns, full revision ledger, current target disposition, pending evidence, candidate contrasts, event sensitivity, and range gate. During final planning, do not assume those server-owned views are already loaded; request only the focused tool observations needed for the decision.
|
||||
2. Propose every explicit event in the latest answer. Use exact source spans and declared date text; propose `revise` only with a server-issued event ID already present in the Dossier.
|
||||
3. After the server stages valid revisions and recomputes diagnostics, choose the single most useful focus. Read focused server observations through `case_read`, `candidate_scan`, `evidence_gap`, or `diagnostic_read`; each result advances the in-run Dossier revision and must inform the next decision. Stop the loop as soon as the evidence supports one useful question, a gated range, or an honest low-confidence result. Do not rotate through domains or ask for finer dates unless the observations show value.
|
||||
4. Write the public reply and one short natural question in the same TurnPlan. When the latest answer adds or refines a concrete event, first summarize that event in the user's own terms, then add one short public-safe sentence explaining why its date and type of change help compare candidate ranges, and only then ask the question. Do not expose internal IDs, scores, contribution details, tools, candidate minutes, chart divisions, houses, or technique names.
|
||||
5. If server validation rejects the TurnPlan, repair it once. If it still fails, accept the generic safety fallback. Offer a range only when the current server Snapshot allows it; otherwise stop honestly at low confidence when no useful question remains.
|
||||
|
||||
A user who answers with a different complete event may have that event saved without overwriting the old target. The old target may receive at most one gentle clarification; repeated diversion closes it and moves the conversation on.
|
||||
|
||||
## Date and privacy policy
|
||||
|
||||
- `day`: never request finer precision.
|
||||
- `month`: normally complete; do not ask for a day merely because a day is absent.
|
||||
- `quarter`: a month may be requested.
|
||||
- `year`: a month or approximate range may be requested.
|
||||
- `range`: refine only when the range is broad and diagnostics show ranking impact.
|
||||
- Health, bereavement, family illness, and relationship questions have higher privacy cost. Once declined in a Case, do not proactively ask that sensitive category again unless the user raises it.
|
||||
|
||||
## Public language
|
||||
|
||||
Use a brief acknowledgement tied to the user's actual event, a brief high-level explanation of why that event helps candidate comparison when an event was added or refined, an optional gated candidate update or limitation, and at most one question. The explanation should describe only observable features such as date precision, event type, or cross-event comparison; it must not name D-charts, houses, astrology techniques, scores, candidate minutes, or hidden reasoning. Do not repeat an unchanged range, over-interpret the event, or turn sparse/conflicting evidence into certainty.
|
||||
|
||||
|
||||
## Analysis process receipt
|
||||
|
||||
The collapsible “分析过程” shown with an assistant message is a durable projection of server execution artifacts. It must remain attached to the correct Turn after refresh; the browser must not infer history from timestamps or manufacture missing phases.
|
||||
|
||||
- Show only phases that actually ran and only tools or techniques confirmed by persisted server artifacts.
|
||||
- Never present an unavailable, skipped, reference-only, or merely supported technique as executed.
|
||||
- A provider reasoning summary may be shown only when the provider explicitly returned displayable reasoning content and the server accepted it through the public safety filter. Never synthesize a replacement summary or expose hidden chain-of-thought.
|
||||
- Do not expose scores, weights, contribution matrices, internal IDs or field names, candidate minutes, tool arguments/results, prompts, sensitive answer text, or model/provider internals.
|
||||
- D60 is neither displayed nor allowed to drive a conclusion.
|
||||
- Historical records without a receipt remain readable. `v4_legacy` and `v5_shadow` retain their existing visible-reply behavior and gain trace display only when compatible persisted artifacts actually exist.
|
||||
@@ -1,11 +0,0 @@
|
||||
{
|
||||
"education": { "primary": ["D24", "Dasha"], "scoreableByDefault": true },
|
||||
"relocation": { "primary": ["D4", "Dasha"], "scoreableByDefault": true },
|
||||
"relationship": { "primary": ["D9", "UL", "A7", "Dasha"], "scoreableByDefault": true },
|
||||
"career": { "primary": ["D10", "A10", "Dasha"], "scoreableByDefault": true },
|
||||
"finance": { "primary": ["D2", "D11", "Dasha"], "scoreableByDefault": true },
|
||||
"family": { "primary": ["D12"], "scoreableByDefault": false },
|
||||
"children": { "primary": ["D7"], "scoreableByDefault": false },
|
||||
"health_pressure": { "primary": ["D30"], "scoreableByDefault": true },
|
||||
"D60": { "primary": ["D60"], "scoreableByDefault": false }
|
||||
}
|
||||
@@ -1,31 +0,0 @@
|
||||
# Event schema
|
||||
|
||||
Preserve the event's subject, related person, domain, event kind, original user wording, declared date text, normalized date range, precision, extraction status, correction lineage, source Turn, and scoreability.
|
||||
|
||||
These source fields are provenance for audit and replay only. Raw wording, source Turn, extraction path, and revision lineage must never add points, change technique weights, or act as a confidence multiplier. Scoring uses only the validated scoreable event contract and the server-owned contribution rules.
|
||||
|
||||
## Subject and scoreability
|
||||
|
||||
- A user's own supported event may be `scoreable`.
|
||||
- A partner relationship event is scoreable only when the server policy explicitly permits it.
|
||||
- Family events, bereavement, illness of relatives, and other third-party events are `context_only` by default.
|
||||
- Do not classify a family health or death event as the user's own health event.
|
||||
- A newly supplied event must not overwrite the event currently being clarified.
|
||||
|
||||
## Date precision
|
||||
|
||||
Keep `day`, `month`, `quarter`, `year`, `range`, and unresolved precision honestly. Never invent a day to complete a month, or a month/year from common sense. Month precision is sufficient by default; finer detail requires a server date-sensitivity reason.
|
||||
|
||||
Relative phrases such as “后来”, “第二年”, or “那时候” may be resolved only by the existing server context-date parser. If that parser cannot resolve them reliably, keep the evidence pending or contextual rather than guessing.
|
||||
|
||||
## Extraction boundary
|
||||
|
||||
Run deterministic extraction first. Model assistance is allowed only for deterministic `event_unparsed`, `pending_review`, or unsupported results. Its output is limited to a source span, summary, domain, event kind, subject, related person, and date text.
|
||||
|
||||
- `sourceSpan` and `dateText` must be continuous substrings of the user's answer.
|
||||
- The model cannot provide normalized start/end dates.
|
||||
- Server date parsing and schema validation remain authoritative.
|
||||
- Invalid, timed-out, or invented model output is rejected and the deterministic pending result remains.
|
||||
- The extraction agent receives no candidate ranges, scores, database write access, or profile mutation authority.
|
||||
|
||||
The raw answer remains in the Turn even when the user skips, declines, changes direction, or the event cannot be scored.
|
||||
@@ -1,37 +0,0 @@
|
||||
# Failure policy
|
||||
|
||||
## Conversation failures
|
||||
|
||||
- Invalid Reasoner output, an unavailable model, or exhausted diagnostic budget uses the deterministic server policy.
|
||||
- Invalid V8 Director output gets one repair attempt, then uses a server-owned fallback. Without a current target the fallback is domain-neutral; with a current target it asks only the necessary anchored factual clarification. Legacy Renderer paths may still use a validated opportunity fallback for compatibility.
|
||||
- A failed or unavailable model-assisted event extraction leaves deterministic extraction and pending evidence intact; it must not fabricate an event or date.
|
||||
- `unknown`, `declined`, and `direction_change` are valid conversation outcomes, not parsing failures and not life events.
|
||||
- After a refusal or direction change, close the target and do not repeat it.
|
||||
|
||||
## Evidence failures
|
||||
|
||||
Stop with low confidence when evidence is too sparse, conflicting, tied, unstable, privacy-costly, or unlikely to add information. Do not turn an internal Snapshot into a public range before its gate passes. Do not keep asking merely to fill a domain checklist.
|
||||
|
||||
A month-dated event is not a failure. Refine it only when date-sensitivity diagnostics show that finer precision could change candidate ranking.
|
||||
|
||||
- LODO retention below `0.8` blocks the public range, as does LOEO below `0.8`.
|
||||
- A missing active-domain required layer or an unclassified missing layer blocks publication. Missing optional layers such as `KP_cusps`, or reference-only D60, do not make the calculation fail and must not be presented as completed evidence.
|
||||
- LOEO/LODO are same-Case sensitivity checks. Until prospective sticky partitioning and calibration exist, the absence of per-Case independent holdout is a deferred safety boundary, not a passed validation.
|
||||
- For `v5_agent`, a missing, timed-out, exceptional, incomplete, tied, or non-discriminating minute-sensitive VedAstro snapshot blocks public range disclosure. SearchEvents failure blocks validation completeness; SearchEvents disagreement is diagnostic only and must not veto, choose, or reverse the local V5 candidate.
|
||||
|
||||
## System failures
|
||||
|
||||
Preserve the existing Job and persistence guarantees: claim/lease, idempotency, completed-job replay, and atomic completion. A renderer, extraction, or VedAstro post-validation failure must not cause partial artifact writes, duplicate completion, profile mutation, a different replay result, or loss of completed local scoring artifacts.
|
||||
|
||||
Do not recover a failed gate by loading an arbitrary external repository, adding provenance-based weight, inventing manual `supports/conflicts` scores, choosing a unique minute, or writing a profile birth time.
|
||||
|
||||
Never log raw sensitive answers to ordinary telemetry. Persist user text only in the approved Turn/evidence stores required by the product contract. Never expose or persist raw VedAstro provider payloads in public output or the analysis receipt.
|
||||
|
||||
|
||||
## Analysis receipt failures
|
||||
|
||||
- Missing phase history, tool traces, technique evidence, or provider reasoning is represented by omission, never by reconstruction or invented text.
|
||||
- A provider reasoning payload that fails source checks or the server safety filter is discarded. Do not fall back to hidden reasoning, a second-model summary, or raw provider metadata.
|
||||
- If a Job fails before durable artifacts exist, show only a safe public failure state; do not expose internal error codes or partial model output.
|
||||
- Legacy records without analysis receipts must continue to load. `v4_legacy` and `v5_shadow` visible replies must not change merely to populate the receipt.
|
||||
- Receipt persistence and Turn association must be replay-safe and owner-scoped. Refresh, completed-job replay, or retry must not duplicate, reorder, or attach a receipt to another Turn.
|
||||
@@ -1,66 +0,0 @@
|
||||
# Output contract
|
||||
|
||||
Public output keeps the existing shape:
|
||||
|
||||
```ts
|
||||
{
|
||||
acknowledgement: string;
|
||||
candidateUpdate: string | null;
|
||||
limitation: string | null;
|
||||
question: string | null;
|
||||
}
|
||||
```
|
||||
|
||||
## Acknowledgement
|
||||
|
||||
Use at most one or two short sentences and refer to the user's concrete experience. Do not repeatedly begin with “已记录” or “我记下了”. Do not use “这个信息很有用”, “它不是单纯的……”, “而是把……”, “接下来最有价值的是……”, or “这样可以避免……”. Do not interpret an ordinary event as a confirmed life turning point.
|
||||
|
||||
## Evidence-value explanation
|
||||
|
||||
When the latest answer adds or refines a concrete event and the final action asks another question, include one short explanation before the question. Explain only why the event's date precision, event type, or relationship to other independent events helps compare candidate ranges. This explanation is required for such turns, but it must remain high-level: do not name chart divisions, houses, astrology techniques, scores, candidate minutes, or hidden reasoning.
|
||||
|
||||
## Question
|
||||
|
||||
For V8, the Director independently chooses the focus and wording from the complete dossier, declined domains, candidate contrast observations, and read-only tool results. The server does not select a domain from a fixed rotation, require domain keywords, or substitute a prewritten domain prompt. `question` is required only when the final action is `ask_question`; otherwise it is `null`.
|
||||
|
||||
The question must:
|
||||
|
||||
- be 8-180 characters, at most two sentences, and contain at most one question mark;
|
||||
- ask one thing only and remain consistent with the structured focus;
|
||||
- include a valid full event anchor when `targetEventId` is present;
|
||||
- avoid reopening a declined event or declined domain;
|
||||
- ask about one possible new event without presuming it occurred when the focus is independent evidence;
|
||||
- contain no internal ID/field, score, snapshot, opportunity, tool call, model name, technique trace such as `D9`/`D60`, or unapproved `HH:MM` birth time.
|
||||
|
||||
Validate semantic consistency and safety, not fixed Chinese words. Reject multi-question transitions such as “另外”, “还有”, “同时再说”, or “并且告诉我” only when they introduce another request. When no current target exists and the model is unavailable, use a domain-neutral recovery question; when a current target requires a factual clarification, the fallback may ask only that necessary anchored fact.
|
||||
|
||||
## Candidate update
|
||||
|
||||
`candidateUpdate` is allowed only when the current range has passed every public gate and one of these is true:
|
||||
|
||||
1. it differs materially from the previous Snapshot's primary range; or
|
||||
2. it is the first Snapshot to pass the public stability gate.
|
||||
|
||||
The no-repeat rule takes precedence: it must be `null` for an unchanged range, insufficient event/domain coverage, LOEO or LODO retention below `0.8`, failed date/neighbor stability, a missing active-domain required or unclassified technique layer, an internal unstable Snapshot, or a repeated equivalent calculation. In `v5_agent`, it must also be `null` when the required VedAstro primary/runner-up post-validation is missing, timed out, failed, tied, incomplete, or unable to distinguish the pair. Missing optional `KP_cusps` and reference-only D60 do not block by themselves. Never state or imply a unique or representative birth minute.
|
||||
|
||||
Do not describe LOEO/LODO as an independent holdout, prospective validation, or calibrated accuracy result. Per-Case independent holdout remains deferred until sticky partitioning and calibration exist.
|
||||
|
||||
## Deterministic fallback
|
||||
|
||||
Fallback follows the same public rules as model output: acknowledge the actual event naturally, briefly explain its public-safe evidence value when present, ask one anchored question, avoid repetition and over-interpretation, and never claim exact-minute certainty.
|
||||
|
||||
|
||||
## Persisted analysis process
|
||||
|
||||
“分析过程” is rendered beside the assistant message as a collapsible, refresh-safe server execution receipt. It is not part of the model-authored public message fields above and is never generated by the Renderer.
|
||||
|
||||
The public projection may contain only:
|
||||
|
||||
- server phases that actually started or completed;
|
||||
- allowlisted labels for candidate calculation, stability diagnostics, and a Reasoner read-only diagnostic that actually ran;
|
||||
- allowlisted techniques proven present in persisted execution artifacts;
|
||||
- an optional provider-explicit reasoning summary accepted by the server safety filter.
|
||||
|
||||
Do not infer missing phases from the final Job phase, and do not label a capability as executed merely because the deployment supports it. If no safe provider summary exists, omit it; never create a substitute or expose hidden chain-of-thought.
|
||||
|
||||
The receipt must exclude scores, weights, contribution matrices, internal IDs and field names, candidate minutes, tool arguments or raw results, prompts, model/provider internals, raw VedAstro requests/responses, internal provider or technique traces, and sensitive user wording. It may state only that an allowlisted read-only post-validation ran and whether the public gate passed. Provenance may support audit linkage only and must never be rendered as added evidence strength. D60 is never displayed. Historical messages without a receipt remain valid, and `v4_legacy`/`v5_shadow` keep their established visible reply semantics.
|
||||
@@ -1,30 +0,0 @@
|
||||
# Product contract
|
||||
|
||||
## Version and ownership
|
||||
|
||||
- Skill: `birth-time-rectification-v8`.
|
||||
- Prompt: `rectification-director-v4`.
|
||||
- Algorithm: `rectification-v5-matrix-scoring-2` remains unchanged.
|
||||
- V8 changes the conversation and semantic-question contracts; it does not replace the V5 candidate engine.
|
||||
- The server owns candidate-minute scanning, the event contribution matrix, Candidate Snapshots, diagnostics, stability gates, Decision Validator, deterministic fallback, Jobs, claim/lease, completed-job replay, atomic completion, idempotency, and persistence.
|
||||
- Preserve `v4_legacy`, `v5_shadow`, and `v5_agent` deployment behavior. Shadow artifacts must not change the legacy visible reply.
|
||||
|
||||
## Result boundary
|
||||
|
||||
The product can return a candidate time range only after deterministic minimum-event, minimum-domain, and stability gates pass. An internal or unstable Snapshot is not a public result. A repeated calculation of the same primary range is not a new update.
|
||||
|
||||
`canConfirmExactMinute` is always `false`. The product must not present a unique minute or representative minute as the user's true birth time, and rectification completion must not automatically write `profiles.active_birth_time`.
|
||||
|
||||
When evidence is sparse, conflicting, tied, date-sensitive, or unstable, stop or continue with one genuinely useful question. Never package uncertainty as certainty or extend the interview without a useful active opportunity.
|
||||
|
||||
## Agent authority
|
||||
|
||||
The agent may only:
|
||||
|
||||
1. propose grounded evidence from the latest answer;
|
||||
2. choose and directly write one safe interview question;
|
||||
3. adapt through up to ten unique permitted read-only tool rounds;
|
||||
4. offer a server-generated candidate range that has passed the public gate; or
|
||||
5. stop with low confidence.
|
||||
|
||||
The final planning prompt exposes only the current runtime revision, prior tool observations, capabilities, and tool availability; it does not preload Case, candidate hypotheses, gap, or diagnostic payloads. The available read-only tools are `case_read`, `candidate_scan`, `evidence_gap`, and `diagnostic_read`; they expose the current authoritative server projection on demand. Every successful call becomes an immutable Observation in the in-run Dossier, increments its revision, and is visible to the next Director round. The agent must not create or alter events, normalized dates, candidate minutes, scores, diagnostic results, or profile birth data.
|
||||
@@ -1,63 +0,0 @@
|
||||
# Question policy
|
||||
|
||||
## Agent-directed focus
|
||||
|
||||
In V8, the dossier and read-only tools expose facts, constraints, and candidate-contrast observations. The Director decides which evidence direction is most useful and writes the question. The server must not rotate through a fixed domain list, rank domains with hand-authored recall/privacy weights, require domain keywords, or turn test transcripts and example events into production scripts.
|
||||
|
||||
Candidate contrast may identify discriminating technique layers and all supported missing event kinds. Treat these as observations the Agent can weigh against the complete event ledger, recent conversation, refusals, privacy, and expected value. They are not a server-selected question and must not be copied mechanically into public wording.
|
||||
|
||||
Legacy semantic opportunities remain readable for compatibility and deterministic target clarification. Their `fallbackPrompt` is a failure-recovery surface, not the normal V8 topic selector. A no-target fallback must stay domain-neutral; a targeted fallback may ask only the server-known missing fact for that event.
|
||||
|
||||
### New-event questions
|
||||
|
||||
- Ask whether one relevant event exists; do not imply the user must have experienced a particular category.
|
||||
- The Agent may use its own natural recall cues when useful, but examples are non-exhaustive and never server-required keywords.
|
||||
- Do not invent an age, life stage, year, month, date range, or relative time window. A time or age may appear only when it already comes from accepted user evidence or another server-owned fact.
|
||||
- Compare a proposed direction with the complete event ledger so the next question does not paraphrase an event already supplied.
|
||||
- A missing domain alone is not a reason to ask about it. If no safe, useful question remains, stop with low confidence.
|
||||
|
||||
## One-turn rule
|
||||
|
||||
- Ask one question only.
|
||||
- Prefer the concrete event the user just mentioned.
|
||||
- A targeted question must include a valid text anchor for that event and must not switch targets.
|
||||
- Do not ask a list of questions or combine a clarification with a new-domain request.
|
||||
- Do not invent an event or date.
|
||||
- Do not expose IDs, fields, scores, tools, models, or technique traces.
|
||||
- Reject canned realizations such as `承接……请再说一件……`; a deterministic fallback must still read as one short contextual question.
|
||||
- Validate the question semantically rather than by fixed phrases. For a follow-up about an already accepted event, natural wording must not be rejected only because it omits a token such as `哪次` or `哪件`; a new-event question must still satisfy the existence form above.
|
||||
|
||||
## Renderer validation and fallback trace
|
||||
|
||||
- Analysis history must make each Renderer path auditable after persistence and reload: model question accepted by validation, model question rejected by validation, or server deterministic fallback used.
|
||||
- Record only safe categorical provenance, including the validation outcome, whether server fallback was used, and a bounded reason category such as model unavailable, model failure, or question rejected. Do not store the raw model prompt, rejected prose, hidden reasoning, private scores, or user event text in the trace.
|
||||
- A Renderer rejection followed by a successful fallback is not equivalent to a model-rendered success. Preserve both facts in the same turn's analysis receipt.
|
||||
- The deterministic fallback must remain server-owned and must obey the same existence, recall-cue, non-assumption, anti-invention, and semantic-overlap rules as a model realization.
|
||||
|
||||
## Target disposition
|
||||
|
||||
Respect the reconciled target state:
|
||||
|
||||
- `resolved`: close the target.
|
||||
- `unknown`: close it; do not create an unparsed-event pending item for the refusal phrase.
|
||||
- `declined`: close it and do not proactively return to that event or sensitive category.
|
||||
- `direction_change`: close it and choose another useful opportunity.
|
||||
- `answered_other_event`: save the new event without overwriting the old target; allow at most one gentle follow-up to the old target.
|
||||
- `unresolved`: one follow-up is allowed only when the user has not refused or changed direction.
|
||||
- `not_applicable`: no old target is being resolved.
|
||||
|
||||
The same `targetEventId` may be followed up consecutively at most once. A second answer about another event closes the old target instead of creating a loop.
|
||||
|
||||
## Date precision
|
||||
|
||||
- `day`: complete; never ask for finer detail.
|
||||
- `month`: complete by default. Ask for a day or narrower stage only when diagnostics exist and either `winnerRetentionRate < 0.65` or `candidateClusterRetentionRate < 0.65`.
|
||||
- `quarter`: a month may be requested.
|
||||
- `year`: request a month or approximate range only when useful.
|
||||
- `range`: refine only when it is broad and diagnostics show candidate-ranking impact.
|
||||
|
||||
Before enough events exist to score candidates, a month-dated event should lead to another important dated event, not a request for the exact day.
|
||||
|
||||
## Privacy and stopping
|
||||
|
||||
Health, death, illness, family, and relationship questions carry higher privacy cost. Once the user declines a category in the current Case, do not ask it again unless the user raises it. If no opportunity has enough value, stop with low confidence rather than running a longer questionnaire.
|
||||
@@ -1,51 +0,0 @@
|
||||
# Technique policy
|
||||
|
||||
The conversation refactor does not change the scoring algorithm. Keep `rectification-v5-matrix-scoring-1`, the real Python scan of every minute in the inclusive candidate window, the event contribution matrix, Candidate Snapshots, leave-one-event-out (LOEO), leave-one-domain-out (LODO), date sensitivity, neighbor stability, candidate split, Decision Validator, and deterministic fallback. A cross-midnight window continues into the next calendar day; equal endpoints mean one minute and the maximum window is 1,440 minutes.
|
||||
|
||||
Only server-reported available layers may be described as used. Missing, blocked, reference-only, and research-only layers are not evidence of a result. Do not import or reproduce the portable ZIP's candidate segmentation, manual `supports/conflicts` scoring, fixed unknown-mode blocks, arbitrary/dynamic external repository loading, or `main_repository_enhanced` mode.
|
||||
|
||||
## Public technique availability gate
|
||||
|
||||
- **Required:** only the layers registered for active scoreable domains. Education requires `D24 + vimshottari + narayana`; relocation `D4 + vimshottari + narayana`; relationship `D9 + UL + vimshottari + narayana`; career `D10 + A10 + vimshottari + narayana`; finance `D2 + D11 + vimshottari + narayana`; self health pressure `D30 + vimshottari + narayana`. A missing required layer blocks the public range.
|
||||
- **Optional:** `KP_cusps`, `A7`, `Ashtakavarga`, and `Shadbala`, plus known domain layers that are not required by the active domains. Their absence does not block the public range. In particular, `KP_cusps` is optional.
|
||||
- **Reference-only:** D60. It must not contribute points, satisfy a gate, appear as executed in the public receipt, or drive a conclusion.
|
||||
- **Unclassified:** fail closed. An unknown missing layer blocks publication until classified server-side.
|
||||
|
||||
## Diagnostic use
|
||||
|
||||
- The Reasoner may request at most one allowed read-only diagnostic in a turn.
|
||||
- Send only compact conclusions needed for opportunity selection, not the full contribution matrix.
|
||||
- Date sensitivity determines whether finer date precision is worth asking for.
|
||||
- LOEO, LODO, neighbor stability, and candidate split diagnose fragility; they do not independently authorize public certainty. The public gate requires LOEO and LODO retention of at least `0.8`.
|
||||
- Sparse, conflicting, or unstable diagnostics require a lower-confidence stop or another genuinely discriminating question.
|
||||
|
||||
LOEO/LODO reuse the same Case matrix after subtracting one event or domain. They are not prospective or independent holdout validation. Per-Case independent holdout remains deferred because no sticky train/holdout partition or calibrated acceptance threshold exists; do not claim it is complete.
|
||||
|
||||
## VedAstro post-validation
|
||||
|
||||
- This read-only check is available only in `v5_agent`, after the local stability and range-eligibility gates pass, and only for the server-selected primary and runner-up. It does not rescore candidates or replace `rectification-v5-matrix-scoring-1`.
|
||||
- Minute-sensitive snapshots may test whether the pair is distinguishable. SearchEvents is bounded supporting evidence only and must never select or reverse the final candidate.
|
||||
- Missing, timed-out, exceptional, incomplete, tied, or non-discriminating provider results fail closed for public range disclosure. They do not invalidate or delete the local Snapshot, diagnostics, or Job artifacts.
|
||||
- VedAstro can never authorize a unique-minute claim or profile write. Public output and receipts must exclude raw provider requests/responses and internal provider or technique traces.
|
||||
|
||||
## Technique boundaries
|
||||
|
||||
- Dasha and dated evidence can frame comparison only when present in server results.
|
||||
- D9 and D10 may support relationship and career analysis when available.
|
||||
- Topic-specific layers such as D4, D24, D2/D11, D7, and D30 remain bounded by server capability.
|
||||
- D60 is reference-only and must never drive candidate selection or the public conclusion.
|
||||
- Event provenance is audit lineage only. Source Turn, raw wording, extraction path, and revision lineage must not change contribution points, layer weights, or confidence.
|
||||
- Never expose private scores, weights, contribution values, internal technique traces, or tool/model names in the user-facing message.
|
||||
- No technique result can override `canConfirmExactMinute === false` or authorize an automatic profile birth-time write.
|
||||
|
||||
|
||||
## Public execution receipt
|
||||
|
||||
The analysis receipt reports observed execution, not the complete capability catalog. A technique or diagnostic may be named only when persisted server artifacts prove it ran in that Turn.
|
||||
|
||||
- Candidate-minute scanning and stability diagnostics are shown only on turns that executed them.
|
||||
- A Reasoner diagnostic is shown as an Agent read only when its persisted tool trace records the call; precomputed diagnostics are not Agent tool calls.
|
||||
- Technique labels are derived through a server allowlist from actual contribution/technique metadata. Never expose rule IDs, raw layers, scores, weights, contribution values, matrices, arguments, or candidate minutes.
|
||||
- Unsupported, unavailable, skipped, blocked, reference-only, and research-only layers are omitted rather than shown as missing work.
|
||||
- D60 is omitted from the receipt and must not drive candidate selection, stability claims, or public conclusions.
|
||||
- Provider-explicit reasoning content is not technique evidence. It may appear only as a separately labeled, server-filtered summary and never as hidden chain-of-thought.
|
||||
Reference in New Issue
Block a user