JohnGorri/decision-twin-v0-1

Decision Twin v0.1 encoder seed dataset

This dataset turns the user’s confirmed purchase and creative preferences into sentence-pair classification groups. Each context is phrased as a first-person request that a buying or creative assistant could receive.

Main files

File	Purpose
decision_twin_encoder.csv	Same rows in CSV form.
train.csv, validation.csv, test.csv	Group-safe 80/10/10 CSV splits, generated with seed 42.
decision_groups.jsonl	Group IDs, candidate sets, task types, user-rule tags, and correct options for audit and evaluation. Do not feed chosen_option or rule_ids into the model.
product_catalog.json	Product metadata and official source URLs captured on 2026-09-18.
decision_option_templates.json	Default candidate sets for purchase, yes/no, product color, creative, and home decisions.
group_options.json	A clean JSON map from group ID to context, question, task type, and options. It omits labels and correct answers.
manifest.json	Dataset counts and schema notes.

Encoder schema

Every training row contains exactly these fields:

Field	Meaning
group_id	ID shared by every candidate option for one decision. Use it to rank candidates together. Do not tokenize it as model input.
context	First-person user request only.
question	The decision task, written in a mix of conversational and structured styles.
option	One candidate response. Groups have two to six options.
label	1 for the selected response and 0 for all other responses in the same group.

Score every row in a group_id group, then select the option with the highest positive score. Never score an option in isolation from the other options in its group. The provided CSV splits keep every complete group together. Report decision-level top-1 accuracy or mean reciprocal rank, rather than per-row accuracy.

Prepend the current user preference profile in your preprocessing step at both training and inference. Keeping it outside the CSV lets you update the profile without regenerating the examples.

URL-to-decision input shape

An encoder cannot fetch a URL by itself. A URL can supply factual details for your interface, but the encoder should score the user's own stated situation:

1. Optionally fetch the product page and show the user its name, brand, price, availability, variant, description, and relevant specifications.
2. Have the user establish or edit a first-person context containing the details that matter to their choice, such as I'm thinking about buying this for daily commuting. I need it to fit with most of my clothes.
3. Generate the response candidates appropriate to the task: buy, do not buy, verify a condition, try a lower-risk option, or choose a color direction.
4. Score each candidate with the encoder and return the highest-scoring response. If the top response is conditional, ask for the named missing detail instead of presenting a false yes/no answer.

Keep raw URLs and scraped product fields in application metadata or product_catalog.json; they are not encoder features in this version of the dataset.

Default options and user-added candidates

Start each decision with the matching template in decision_option_templates.json. For example, a product purchase can begin with Buy it now, Pass, Check the missing detail, Try a lower-risk version first, and Compare an alternative first.

If the user supplies an extra option, append it to the same candidate group and rescore every option. Do not score only the new option: the ranking is meaningful only when the default and added candidates compete against the same context and question. For product-color questions, every candidate must come from user input; do not supply default colors.

Product prices and catalog details can change. Each catalog record preserves its retrieval date and original official source URL. The labels encode this user’s stated preference rules; they are not claims that one product is universally better.