Skip to content

DR-009 — Open work packages and low-cost tiers

Converted from docs/decisions/DR-009-open-work-packages-and-low-cost-tiers.md to MADR (backlog B25). The text is unchanged; its sections are grouped under the MADR headings below, in their original order within each group.

Context

1. A data class for quote-stage and partner work

Correction to my earlier wording: not all client-related work is "client data".

Class Example Allowed on
public Factsheets, NAVs, product brochures, regulator circulars Any tool, free included
indicative (new) Quote inputs without identity: age or age band, city tier, sum assured, vehicle make/model/year, premium budget, smoker yes/no; B2B partner enquiries before they commit Free agents and tools allowed, provided no identifier is present
internal Code, plans, coordination data Paid tools; free tools only for public or synthetic parts (DR-008)
client Name, PAN, Aadhaar, phone, email, address, exact date of birth, policy or folio numbers, bank details, health records Approved, paid, India-region providers only; never free tools, never outsiders

The line between indicative and client is identity. Quotes stay indicative while iterating with a client or partner. The moment a real identifier enters (usually when the client or partner decides to transact), the work moves to the client class and its tools. Quote tools must have no fields for identifiers, and agents strip any identifier pasted in by mistake.

2. Open work packages (OWP)

For requirements that sit outside our current priorities but must be ready before real use, such as research on public data, parsers, converters and prototypes.

Package contents (one repository or folder per package, no estate code): - REQUIREMENT.md: purpose, inputs, exact output format (schema), edge cases, examples. - samples/: public input samples and expected outputs. - acceptance/: automated acceptance tests the delivery must pass. - RULES.md: licence (our ownership of the deliverable), allowed dependencies, no network calls except the named public sources, no secrets, delivery format.

Who can take a package: free AI accounts (ChatGPT Go, Gemini free, and others), gig workers at trust level T0 (DR-008 §7), or our own agents when idle.

Intake (before anything enters our repositories): 1. Acceptance tests pass on our runner, in isolation, without network access beyond the named sources. 2. Security review: dependency and licence scan, no obfuscated code, no unexpected network calls or file writes; a Claude or paid-agent review for cx:3+. 3. Data check: outputs match the schema on fresh samples, not only the provided ones. 4. Merged as a component (registered in docs/registers/components.md) through a normal MR; the package is then closed.

Register: docs/registers/open-work-packages.md lists every package, its status (open, taken, delivered, accepted, rejected), who took it, and the review outcome.

First candidate: AMC factsheet parsers. About 50 AMCs publish monthly factsheets; we have no working parser today (only an ad hoc ICICI script on a local PDF in mm-crons). Source of links (Atul, 17 Oct): AMFI's website lists every AMC's monthly factsheet link (AMCs must submit them); the PDFs stay on AMC servers. The AMC master is our Providers / Product Owners API. A small MM-Cron job (built by our agent, not a package) collects the AMFI link list monthly and reconciles it with the Providers API: new, closed or merged AMCs are flagged for MCRM. The parser packages then take each link as input. One package per AMC (or per factsheet layout family): input = the AMC's public factsheet PDF; output = a fixed JSON schema (TER, AUM/fund size, inception date, benchmark, fund manager, portfolio holdings, ratios as reported). The schema comes from MM-Cron's priorities 2–4 (owner note 52), so accepted parsers drop straight into MM-Cron jobs. Start with the AMCs whose funds our clients hold most.

Other candidates: ULIP fund NAV collectors per insurer (public pages); quote calculators on indicative data; research packs on public regulations and product brochures.

3. Extending subscriptions on demand

Tool Extend on demand Use
Claude (paid plan) Extra usage can be bought on the account when the weekly allowance runs out Short bursts for high-priority Claude work instead of a plan upgrade; record each purchase in the capacity register
ChatGPT Go No extra credit for Go users (Atul); free in India until Dec 2026, ₹399 a month after (Atul) One account per person for other developers, agency staff and gig workers, and for open work packages; each person signs up themselves (accounts are personal, not shared)
Gemini free tier Fixed daily limits (capacity register) Preflight, triage, open-work-package attempts
Metered APIs Pay per use, capped (DR-007, ODM-1) Unattended work

Rules for free accounts: turn off "use my content to improve the model" where the setting exists; only public, indicative or synthetic material; anything they produce passes the intake in §2.

Options

Not stated separately in the original record.

Decision

4. Decisions for Atul

  • DCL-1: Adopt the indicative data class (quote and partner work without identifiers on free tools; identity moves work to client)?
  • OWP-1: Adopt open work packages with the intake rules, and start with AMC factsheet parsers?
  • SUB-1: Extend capacity by buying Claude extra usage for bursts, and by giving each additional developer or agency user their own ChatGPT Go account?

Consequences

Not stated separately in the original record.