Finding Lifecycle, Evidence Assurance, and Review — Technical reference

This reference owns the implementation contracts of BND-FINDINGS. Read the package guide for usage, configuration, dependencies and upgrades. Generic execution, isolation and admission remain governed by Platform Documentation.

Data model and interfaces

DataModelPackage: DM-FINDING

Owned entities: finding, evidence link, confidence, severity, status, watch condition, review task, resolution, contradiction, derivation.

InterfacePackage contributions: IF-FINDINGS-LIFECYCLE.

Each business object and source reference remains tenant- and purpose-scoped. The package owns schema evolution and declared migration behavior; the platform enforces schema registration, authorization and versioned installation. Consumers reference this model rather than creating competing canonical copies.

Workflows

WorkflowPackage: WFP-FINDING-LIFECYCLE

• Finding Intake
• Independent Evidence Verification
• Finding Reconciliation
• Contradiction Preservation
• Human Review Routing
• Confirmation
• Watch Monitoring
• Resolution and Reopening
• Derived-Finding Invalidation

These are named definitions within the workflow package, not separate invented workflow IDs. Workflow runs resolve package versions, actor and purpose, authorized inputs, retries, review gates and output schemas through the environment lock. Temporal provides durable execution and Kafka carries declared lifecycle/domain events.

Policies, evaluations and tools

POL-FINDING-DISCLOSURE, POL-HUMAN-REVIEW, EVAL-FINDING-EVIDENCE, evidence, entailment, reconciliation, and review tools.

Qualification covers the selected model/runtime profile, languages, access scope, failure handling and the package's domain-specific outcomes. Tool execution uses the platform gateway; package code cannot increase its own permissions or write directly to external systems.

Owned agents

P03 — Evidence Verification Agent

Agent ID: effority.evidence-verification

Purpose: Independently verifies that each material field in a candidate artifact is supported by authorized evidence and that every cited source entails the stated claim.

Triggers: Candidate finding, recommendation, answer, summary, report, alert, or external draft.

Inputs: Candidate artifact, field-to-evidence map, source versions, policy decision, and validation profile.

Outputs: Field-level SUPPORTED, PARTIAL, CONTRADICTED, or UNSUPPORTED decisions; citation coverage; explanation; and review disposition.

Tools: evidence.resolve, transcript.window_read, document.fragment_read, citation.hash_verify, and independent verifier model routes.

Review and limits: It uses an independent prompt or model route from the producing agent. It never repairs a material unsupported claim by inventing new content.

Primary metrics: Citation precision, entailment accuracy, unsupported-claim escape rate, false rejection rate, and verification latency.

P04 — Finding Reconciliation Agent

Agent ID: effority.finding-reconciliation

Purpose: Consolidates findings without erasing source disagreement or historical state.

Triggers: Validated candidate artifact, source correction, new document version, review outcome, or related-object update.

Inputs: Candidate and historical artifacts, evidence hashes, object links, validity periods, review states, and derivation graph.

Outputs: New finding, linked update, duplicate merge, explicit contradiction, supersession, reopening, invalidation, or no-change result.

Tools: finding.read, finding.derive, graph.read, timeline.read, and artifact.invalidate.

Review and limits: Human-confirmed history remains preserved. The agent does not use majority voting to suppress conflicting evidence.

Primary metrics: Duplicate rate, incorrect-merge rate, contradiction preservation, selective-recomputation coverage, and review corrections.

P05 — Human Review Routing Agent

Agent ID: effority.review-routing

Purpose: Selects the authorized review workflow, reviewer role, priority, deadline, disclosure level, and escalation policy for a validated artifact.

Triggers: Material finding, ethics candidate, contractual acceptance, low-confidence high-severity result, external draft, contested finding, or policy exception.

Inputs: Artifact type, severity, confidence, affected subjects, intended use, source sensitivity, tenant policy, and reviewer authority matrix.

Outputs: Review task, queue, permitted evidence view, SLA, required approvals, escalation path, and notification scope.

Tools: policy.read, reviewer.resolve, workflow.create, and notification.draft.

Review and limits: It routes work but never confirms a finding or assigns itself review authority.

Primary metrics: Correct queue rate, reassignment rate, overdue reviews, unauthorized disclosure events, and SLA compliance.

Implementation profiles

Minimum Finding Contract

Every Finding contains:

• type and subtype;
• affected object and people;
• neutral descriptive text;
• primary evidence and context;
• supporting sources;
• time or period;
• model, version, prompt/rule, and relevant parameters;
• calibrated confidence and source quality;
• severity and potential impact;
• alternatives or uncertainties;
• status: suggested, under review, confirmed, modified, rejected, or withdrawn;
• reviewer, reason, and date;
• derived actions;
• policy that authorized processing;
• finding-specific visibility and retention.

Structured Finding Extraction

Analysis is implemented in four steps:

1. Map: every topic is processed with its context window, speakers, and retrieved sources.
2. Normalize: dates, people, objects, currency, priority, and commitment verbs are converted to the canonical schema.
3. Reduce: duplicates are merged, updates are linked to earlier findings, and contradictions are resolved without concealing them.
4. Verify: an independent verifier confirms that each material field is supported by a citation and that the citation actually entails the statement.

Extractors produce separate objects for:

• decisions;
• proposals;
• commitments;
• actions, owners, and dates;
• pending questions and answers;
• acceptances and rejections;
• risks, blockers, dependencies, and mitigations;
• objections;
• needs, commercial signals, and next steps;
• requirements, constraints, and scope changes;
• candidate alerts and recommendations.

Deterministic rules handle dates, quantities, codes, and obligation expressions; NER and entity linking handle identity; and LLMs handle complex context and relationships. No extractor writes directly to an external system.

Confidence Calibration

Finding confidence comes from a calibrator trained on reviews, not an arbitrary average. Its variables include:

• ASR and diarization quality;
• document quality and authority;
• citation support;
• agreement among extractors;
• temporal consistency;
• entity ambiguity;
• distance from the evaluated domain;
• historical precision for the class, language, and model.

The calibrator produces an empirical probability and band. Severity represents potential impact and is never used to inflate confidence. The interface always displays both separately.

Integration boundaries

Confidence is not severity or truth. Confirmation of a finding does not itself approve an external action or establish an ethics violation.

Owned screen contracts: SCR-MTG-03, SCR-FND-01, SCR-FND-02, SCR-FND-03, SCR-FND-04, SCR-FND-05.

See solution workflows for cross-package behavior. Screens, agents and workflows keep one canonical owner even when other bundles invoke or enrich them.