← Rohas Legal AI: ConciliationCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Rohas Legal AI: Conciliation
Snapshot Sep 30, 2026 · 23:14 UTC · version 0.2.1
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "Drafts a structured settlement proposal for use in conciliation or mediation, converting a party's interests, priorities, valuation, non-monetary needs, and authorised concessions into clear conditional terms without accidentally creating a concluded settlement. Use when a user wants to make, revise, compare, or package an offer for a facilitated settlement process, including opening proposals, option packages, staged payments, reciprocal concessions, or mediator-transmitted terms. Distinct from settlement-terms-drafter, which documents a deal after agreement rather than proposing one.",
"included_files": [
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 268
}
],
"name": "conciliation-proposal-drafter",
"skill_md_contents": "---\nname: conciliation-proposal-drafter\ndescription: Drafts a structured settlement proposal for use in conciliation or mediation, converting a party's interests, priorities, valuation, non-monetary needs, and authorised concessions into clear conditional terms without accidentally creating a concluded settlement. Use when a user wants to make, revise, compare, or package an offer for a facilitated settlement process, including opening proposals, option packages, staged payments, reciprocal concessions, or mediator-transmitted terms. Distinct from settlement-terms-drafter, which documents a deal after agreement rather than proposing one.\n---\n\n# Conciliation Proposal Drafter\n\n## Purpose\n\nTurn authorised settlement positions into a proposal that is understandable, internally consistent, capable of acceptance or counterproposal, and clearly distinguished from a final binding agreement.\n\n## Required inputs\n\nObtain:\n\n- the parties and disputes to be settled;\n- the user's side, objectives, priorities, and settlement authority;\n- the relief claimed, realistic exposure, supplied valuation, and non-monetary interests;\n- the intended audience: other party, conciliator only, or both;\n- prior offers, accepted points, rejected points, and live deadlines;\n- payment capacity, timing, security, tax assumptions, confidentiality needs, and implementation constraints; and\n- the governing procedural framework for confidentiality, privilege, admissibility, and costs consequences.\n\nDo not invent a bottom line, authority, valuation, concession, or threat. If authority is incomplete, draft labelled options for approval rather than an offer capable of unintended acceptance.\n\n## Method\n\n1. Classify the document as an opening proposal, revised offer, option package, mediator-only suggestion, or term sheet subject to final documentation. State its intended legal status and recipient.\n2. Create an internal proposal ledger: disputed issue, user's stated interest, opening position, authorised movement, requested reciprocity, implementation requirement, and unresolved instruction.\n3. Separate factual background from bargaining language. Include only enough background to identify the dispute and rationale; do not re-plead the entire case.\n4. Draft terms as linked exchanges where appropriate: `If A, then B`. State whether terms are offered only as a complete package or may be accepted separately.\n5. Make money terms operational. Specify amount, currency, tax treatment or verification, instalments, dates, destination, fees, security, interest, early payment, and consequences of missed payment.\n6. Make non-monetary terms operational. Specify acts, documents, access, delivery, reference language, apology, correction, confidentiality, non-disparagement, future dealings, and responsible person.\n7. Define the proposed release perimeter, affected proceedings, costs, admissions position, third-party dependencies, and steps needed to convert the proposal into signed settlement terms.\n8. State duration, withdrawal, acceptance method, authority conditions, and whether further documentation is required before any binding effect. Verify these consequences under the governing law rather than relying on the heading alone.\n9. Use neutral, solution-focused language. Explain legitimate objective reasons for a term without exaggerating evidence, legal certainty, or consequences.\n10. Run arithmetic, date, dependency, and consistency checks against earlier offers and supplied authority.\n\n## Output\n\nProduce:\n\n1. **External proposal**, ready for legal and client approval.\n2. **Term table** — issue, proposed resolution, responsible party, deadline, dependency, and status.\n3. **Cover note**, if requested, stating process status and response mechanics.\n4. **Internal approval list** — assumptions, authority still needed, valuation checks, and terms requiring legal verification. Keep this separate from the external document.\n\n## Guardrails\n\n- Do not imply that a proposal is binding or non-binding solely because it is labelled that way; verify offer, acceptance, and form requirements.\n- Do not disclose the user's walk-away position, private instructions, or mediator-only information without express authority.\n- Do not fabricate litigation risk, evidence, deadlines, competing offers, or ability to perform.\n- Do not use `without prejudice`, confidentiality, or costs labels as universal protections; confirm the applicable regime.\n- Do not draft a release broader than the disputes and parties the user has authorised for settlement.\n"
}SHA-256 of public snapshot: c38347be2c2bbb8bf8b5040fb64aebc4030c2e8aee271eb20fef507fd7196e69