Beginner course · Lesson 3 of 6
Keep this guide beside your Ruthless chat. Copy one prompt, add the example it asks for and paste it into “Message Ruthless”. Nothing is sent until you choose to send it.
The short answer
List the information your app needs to remember, then trace where it writes and reads each item. GetRuthless can explain redacted storage code or a schema you supply, but a button label or a surviving page reload does not establish where the information lives.
What you will learn
Our notes app has several kinds of information. The words currently being typed may be a temporary draft. A saved note needs durable storage. The signed-in person has an account identity. The screen may also remember a display preference. These items can live in different places, so “the app has a database” is not a complete explanation of its data.
Browser storage stays with a browser on a device. A remote database can hold information away from that device. A database often organises information into records; in a table, each row might be one note and each column a field such as title, text or owner. Other databases organise records differently. Your goal is to understand the project you actually have, not memorise a universal structure.
Collect a small data description
Use the checked Save trail from lesson two. In your building tool, locate the write function and the function that loads the list. Look for a schema or data model: a description of the names and kinds of information stored. Ask the tool to identify those files without changing them. If you have a database dashboard, field names with invented example values are enough; real customer records are unnecessary.
Bring GetRuthless the relevant excerpts and a short observation: “My test note survives a reload” or “It disappears when I reopen the page.” Remove credentials, personal information and real note contents. An owner identifier may be replaced consistently with a label such as user_A, preserving the relationship without exposing the original value.
Ask where each piece lives
Open GetRuthless chat and send the prompt below. Ask it to distinguish temporary screen state, device storage and remote storage using evidence. “State” simply means the information a part of the app currently holds. A draft can be present in screen state even when no saved record exists.
Then ask what makes a note belong to a user. An owner field records a relationship; it does not automatically enforce privacy. The next lesson examines that enforcement. For now, identify the field and the code that supplies or uses it, with unknowns kept visible.
Explain my app data to a beginner using only the supplied material. Do not change files or suggest deleting data. Here is my checked save trail, redacted write/read code and field list: [paste]. For note text, identifier, owner and any other fields, explain what each means, where it lives, how it is written and how it is read. Separate temporary state, browser storage and remote storage. Mark unknowns. Give one safe test using invented data in my test version, and explain exactly what its result can and cannot prove.Example: a note and its fields
Example output: “A note record contains id, body and owner_id. id distinguishes this note from other notes. body stores its text. owner_id associates it with an account. The supplied read function asks for notes with that owner. I cannot verify whether the storage system independently enforces that restriction because its rules were not supplied.” This explains both the data and the limit of the evidence.
Check each field name against the actual schema and code. In your test version, save an invented note with a recognisable phrase, reload, then edit that same note and reload again. Observe whether the edit changed the existing record or created another item. Do not delete or alter production data to test your understanding. A second device can help distinguish device-only storage from shared storage, but use only a test account and never treat that observation as a privacy audit.
Explain one record yourself
Small task: describe a saved note without using the word “database”. For example: “One stored item has a unique label, some text and a link to its owner.” Quiz: if a note survives reload, must it be on a remote server? No; browser storage can survive reload too. The read/write code helps explain which case applies.
Keep the checked field list, the storage location and the owner relationship. Carry those into lesson four with any sign-in or access-rule excerpts your building tool can identify safely. We will separate knowing who someone is from deciding what they may read.
Common questions
Should I paste the whole database export?
No. Supply field names, relevant rules and invented records. A full export adds private information and rarely helps explain a single read or write path.
Is the database also my backup?
The current database is the active data store. A backup is a recoverable earlier copy or recovery mechanism. Ask how your project actually backs up and restores data; do not assume storage automatically provides the recovery you need.
Sources & further reading
The example prompts and workflows are GetRuthless guidance. Source references support the concepts explained; they are not an endorsement of GetRuthless.
Put the guide into practice.
Open Ruthless and choose an available standard or abliterated model suited to your task. Copy a prompt above, add the context it asks for and check the result. You can compare models in the same workspace; see current pricing before sending requests.