Decomposing an analytical task: model proposals, explicit checks, human decisions

Start with the question, not the agent count

Consider a policy analyst asking, “Did the delegation reverse its commitment after the amended draft?” A useful answer needs at least four distinctions: which delegation is meant, which statement was a commitment, which draft was available at the time, and what would count as a reversal. Splitting this into four chat agents does not resolve those distinctions. It may merely create four places for the same assumption to spread.

ReAct interleaves reasoning and tool use; DSPy expresses language-model pipelines as modules that can be optimized against a metric. Both are useful precedents for composition. Neither paper establishes the right domain model or review policy for this question. Those are application decisions, and they need their own tests. [1][2]

Put a contract at each change of responsibility

Our proposed decomposition starts with retrieval of source passages and their document versions. A model proposes actors, attributed claims, dates, and possible relationships. Deterministic checks then examine identifiers, required fields, source offsets, allowed relation types, and version compatibility. A reviewer assesses ambiguous interpretation before a proposed change can enter a reviewed capsule.

The useful boundary is the artifact between steps. A later worker should receive a bounded assignment and relevant records, not an undocumented paraphrase of the previous worker’s conclusion. PRAXIS is the workspace for assigning and reviewing the work; DIALECTICA is the knowledge and review boundary we are developing. This describes the intended integration, not a completed autonomous pipeline.

A proposal that can be rejected precisely

The fictional record below separates extraction from promotion. Its revision precondition prevents application to a capsule that changed while the task was running. The evidence pointer identifies a document version and passage; stable identifiers let a correction refer back to the proposal.

SHACL provides one established way to validate graph records against declared conditions. Conformance means the supplied graph satisfies those conditions. It does not mean that “possibly qualifies” is the right reading of a diplomatic statement. PROV-O offers a vocabulary for recording the extraction activity, source entities, and subsequent review. [3][4]

{
  "proposal_id": "proposal-042",
  "operation": "propose_relation",
  "base_capsule_revision": "rev-17",
  "subject": "statement-12",
  "relation": "possibly_qualifies",
  "object": "commitment-08",
  "evidence": [
    {
      "document": "draft-b",
      "revision": "2",
      "paragraph": "14"
    }
  ],
  "interpretation": "The condition may narrow the earlier undertaking.",
  "review_state": "pending"
}

Replay is narrower than reproducibility

A pure reducer can replay the same accepted operations into the same state if ordering, identifiers, rules, and inputs are fixed. Re-running a model is a different experiment: provider behavior, retrieval results, and sampling can change. Store the original proposal and validation report rather than assuming a second call will recreate them.

Retries also need an idempotency key. Otherwise a timeout can turn one proposal into two commitments. Parallel workers can produce individually valid but mutually inconsistent changes; a shared revision check should force reconciliation. A rejected proposal should retain its reason, while sensitive source content follows the applicable retention policy.

Measure the cost of the boundaries

More steps can reduce the scope of each prompt while increasing total instructions, tool output, retries, and latency. Small calls are not automatically cheaper. Record preprocessing, per-task input and output tokens, validation time, and reviewer effort separately. Cache reuse is only meaningful when the evidence and rules that justified the cached artifact remain valid.

Test the workflow against a single-call baseline and a simpler retrieval-and-review baseline on the same questions. Inject a wrong entity alias, a missing condition, a stale document revision, and a duplicated retry. Measure where each error is detected, whether any reaches a reviewed artifact, and how much work correction requires. We have not established a TACITUS performance advantage from this design.

Two bounded checks, with a visible failure receipt

The website source checker compares exact pinned passages and flags a narrow set of certainty phrases. The chronology checker prevents a Day 15 record from entering the Day 8 task. Both return proposed artifacts to the same human review board, with actual checks, failure details, cancellation and exact input binding. A changed task or unsupported language has no compatible replay, rather than a recycled answer presented as fresh analysis. Imported method text is data; it cannot enlarge the harness’s operations. [5]