product: evidence-grounded administrative correspondence workflow #181

Goal

Adapt the supplied “Official Administrative Reply & Demand for Documentary Evidence” template into a reusable, source-grounded SIDERETH correspondence workflow. Do not copy it verbatim as a legally authoritative template and do not create a generic “legal engine.” SIDERETH remains the canonical Rust domain/runtime core, with existing Document, LegalSource/LegalProposition, Procedure, Evidence/Provenance, authorization, and persistence contracts.

User workflows (must be separate document tracks)

1. Reply/representation to an issued notice: respond to a named notice; state verified facts; request the identified statutory basis, calculation and relevant supporting records; raise tailored questions/objections; ask for a reasoned written response; request pause/extension only where an applicable process makes that request meaningful.
2. Right to Information request: separately address the appropriate CPIO/SPIO/Assistant PIO or designated channel; seek existing records/documents/inspection/certified copies; apply the relevant Central/State RTI rules, fees, and public-authority route; track the statutory response period and appeal dates.
3. Follow-up, grievance, first appeal or other remedy: create only when the case facts and applicable procedure support that path. Do not confuse a reply to a fee notice with an RTI request or an appeal.

Do not combine all three into one self-executing “notice.”

Architecture fit — reuse before abstraction

• Document / DocumentVersion: store each source notice, generated draft, approved/sent letter and received response as distinct versions/artifacts. Never overwrite the original notice or source evidence.
• EvidenceOriginal / content hash / provenance: preserve uploaded notice, enclosure, postal receipt, tracking results, acknowledgement, email headers and authority reply as distinct evidence artefacts. Hashes prove byte integrity, not legal authenticity.
• LegalSource / LegalProposition / LegalSourceRegistry: record jurisdiction, issuing authority, citation/official URI, publication/effective dates, version/retrieval time, verification status, and whether a proposition is verified law, official procedure, user-supplied fact, inference, uncertainty, disputed interpretation, or professional-review-required. Resolve law based on jurisdiction and the event/date, not a hard-coded current string.
• Procedure / ProcedureStep: encode route-specific checklists and statutory deadlines as versioned procedures with source references. Do not build a general-purpose interpreter or duplicate the authorization evaluator.
• Existing authorization + privacy policy: protect uploaded records and any sensitive data; keep generation, external AI processing, export and dispatch as separate purpose-bound actions with explicit user choice.
• Existing persistence / Unit of Work: use typed authoritative command paths for state changes. Do not introduce a new document database, workflow engine, event loop or generic legal engine for this feature.

Document fields and workflow

Required case inputs: issuing authority/department; recipient; notice/letter number and date; delivery date/proof; subject/fee or levy; alleged statutory/order basis (as stated in notice); amount and calculation where relevant; jurisdiction/state/local body; response date stated in the notice; desired outcome; factual assertions with source references; supporting records; contact/return address as needed.

Template fields remain explicit, typed, validated placeholders. Do not infer names, notice references, fees, statutes, dates, addresses or events. Missing or conflicting inputs must block finalization or remain visibly marked for user completion.

Suggested lifecycle:
Draft → SourceChecked → UserFactChecked → LegalReviewRequired/Reviewed → UserApproved → Sent → DeliveryEvidenceRecorded → ResponseReceived | DeadlinePassed → FollowUp/AppealReview → Closed

A passage of a deadline must never automatically mark a dispute accepted, a fee invalid, consent withdrawn, or liability extinguished. It can raise a reminder to assess the next legally available step.

Legal accuracy guardrails based on review of supplied template

1. The template's “silence/non-response = tacit agreement/acquiescence” and “self-executing instrument” assertions must not be generated as legal effects. Supreme Court case law treats acquiescence as context- and conduct-dependent; inaction does not in every case imply consent. Use a neutral record-preservation sentence and reserve applicable remedies instead.
2. Do not say all public records must be supplied within 14 days under BSA sections 74–75, or that an officer must provide an affidavit of completeness. BSA §74 classifies public/private documents; §75 concerns certified copies of public documents a person has a right to inspect and permits the prescribed legal fee; §76 addresses proof by certified copies. Access rights, exceptions, route and fees must be identified separately.
3. For an RTI information request, use the Right to Information Act route when applicable: §2(j) includes inspection, notes/extracts, certified copies and electronic access; §6 governs requests; §7 ordinarily sets a 30-day decision period and a 48-hour rule for information concerning life or liberty; §§8–10 can affect disclosure; §19 provides appeals. Apply the right Central/State rules and the public authority's procedure. Do not impose the response-to-notice 14-day requested timeframe on RTI as a substitute for its statutory timetable.
4. BSA has been in force since 1 July 2024 and repeals the Indian Evidence Act subject to the savings in BSA §170 for specified pending matters. Do not insert old IEA citations as generally “analogous”; use a saved IEA route only after checking whether the savings provision applies.
5. Article 265 says no tax may be levied or collected except by authority of law. Whether a particular amount is a tax, fee, service charge or other levy is a legal classification question. Ask for the enabling provision, competent authority, notification/rule, calculation and appeal route; do not conclude the levy is invalid merely because the user disputes it.
6. Articles 13, 14, 19, 21, 32, 226 and 300A should appear only when relevant to the facts and reviewed claims. Article 51A(h) expresses a Fundamental Duty to develop scientific temper, humanism and inquiry/reform; do not present it alone as the source of a disclosure entitlement or a veto over statutory payment obligations.
7. Do not generate blanket allegations that enforcement is automatically trespass, tort, extortion or criminal intimidation. BNS criminal offences have statutory elements and require fact-specific assessment. Prefer “I reserve the right to pursue remedies available under applicable law” unless a particular claim is verified and appropriately reviewed.
8. Remove “No consent–No contract” and irrevocable withdrawal of consent as default boilerplate for statutory levies. A statutory obligation is not necessarily a consensual contract.
9. Replace “under penalty of perjury” with an ordinary declaration/signature, unless a prescribed affidavit/oath or other specific legal requirement applies.
10. Under IT Act §12, do not assert a blanket legal duty for every office to acknowledge a routine email. Request acknowledgement as an operational matter and preserve dispatch/delivery evidence under the applicable route.

These are drafting controls and issue-spotting criteria, not a conclusion about any particular fee or notice. Exact rights, limitation periods, exemptions and remedies require jurisdiction- and fact-specific checking.

Source and citation requirements

Prioritize current official material: India Code / Gazette / official authority circulars and forms; then official court judgments. Persist legal source version, jurisdiction, effective period and retrieval timestamp. Each legal claim in the generated letter should have an inspectable source reference or be explicitly marked as user assertion, inference, uncertainty or review-required. Do not invent citations or silently replace user-provided facts.

Acceptance tests

• A fee-notice reply and an RTI application produce distinct forms, recipients, deadlines and legal instructions.
• Missing authority, jurisdiction, notice references or source evidence cannot be silently filled by AI.
• A generated legal statement without a source/claim classification is flagged; high-risk legal assertions block “ready to send” until the user confirms or review resolves them.
• “Silence = tacit agreement,” “self-executing instrument,” automatic withdrawal of statutory liability, blanket criminal accusations and universal IEA citations are blocked as default legal effects.
• RTI deadline/appeal reminders derive from the selected applicable procedure and record exact trigger dates.
• The generated draft preserves the user's section structure where useful, while allowing unsafe boilerplate to be removed or replaced with neutral, fact-specific wording.
• Original notice, generated draft, sent version, attachments and dispatch/delivery proof are separate immutable/versioned artifacts with hashes/provenance; never overwrite source material.
• Export is separate from dispatch; SIDERETH does not send a legal notice automatically without explicit user approval.
• Privacy minimization, access control, deletion/retention policy and audit trails are tested.
• Keep implementation cohesive with current modules. Create a new module only if the document-generation contract proves to be an independently changing boundary. No new language, interpreter, JIT, event loop, or package split for v0.1.
• Preserve exactly nine active branches, archive first, inspect unique commits, and merge only with exact-head required checks green.

First milestone

Deliver the source-backed workflow specification and a minimal deterministic field/claim checklist first. Then implement the smallest conformance tests against existing Document, LegalSource, Procedure, Evidence and Provenance boundaries. Do not start by generating a legally assertive letter or by adding a general-purpose rule engine.