{
  "feed_url": "https://publishing.oyotta.org/research/practice/feed.json",
  "home_page_url": "https://publishing.oyotta.org/research/practice/",
  "items": [
    {
      "_oyotta": {
        "object_id": "STUDY:a-listening-comparison-you-can-repeat"
      },
      "content_text": "A listening notebook becomes useful when it records something you can revisit. “This music changed everything” may describe a sincere experience, but it gives your next session no starting point. Try a narrower question: when I return to the same passage, do I notice the same change, at approximately the same point, and can I describe what I heard before explaining what I think it means? This exercise is a proposed listening method, not a test of the music’s value or a promise of a particular psychological effect.\nChoose one OYOTTA work through its canonical catalogue page and listen using its authorized player. Record the displayed title and the link. Select a short passage that you can locate again. Use your own approximate playback positions; do not copy timestamps from a different edition and assume they match. If the player does not display time, identify a repeatable landmark in plain language. Keep the listening level comfortable and avoid changing it during the comparison.\n\nThe first column is observation: a sound enters, a repeated event stops, a voice becomes audible, or a passage feels denser. Write only what you can identify in this particular session. The second column is interpretation: the change suggests distance, suspension, urgency, or return. The third column is uncertainty: you may be hearing a background sound, your player may have changed quality, or you may simply be unsure where the event begins.\nConsider this invented notebook example: “At my marked point, the repeated sound is no longer obvious” is an observation with a limit. “The work has abandoned its earlier order” is an interpretation. “I cannot tell whether the sound stops or becomes masked” is an uncertainty. These sentences are not findings about a particular OYOTTA recording. They demonstrate how to avoid making an interpretation look like a production fact. You can preserve a strong personal response without attributing an intention to the artist.\n\nOn the second pass, use the same passage and playback setup if possible. Before opening your first notes, write what you notice. Then compare the two records. Mark an observation as repeated only when both descriptions point to the same audible event. Similar emotional language is not enough to establish that the event itself repeated. If the setup changed, record that difference instead of treating the comparison as controlled.\nA disagreement is useful. It can suggest that your attention moved, that an earlier description was too broad, or that playback conditions mattered. It does not by itself show that one session was wrong. Select one disagreement and listen once more with a specific question. Stop when you can state either a revised observation or a clear remaining uncertainty. Repeating the entire track without a question can create more notes without resolving the original problem.\n\nCount the observations you attempted to revisit, the ones you located again, and the ones you could not resolve. For example, if you revisited five observations and found three again, the repeat count is three out of five for your notebook under those conditions. It is not a reliability estimate for every listener, evidence of artistic quality, or a ranking of the recording. Keep the denominator visible. A count of three means little without knowing what was attempted.\nIf you compare two works, use the same amount of listening time and the same question for each. Reverse their listening order in a later session if convenient, and record the order. This can help you notice an order-related difference in your own experience; it does not establish causality. Do not turn a one-person exercise into a claim about an audience.\n\nFinish with one paragraph containing a specific observation, your interpretation, and an uncertainty that remains. Add the canonical source link so another reader can locate the work. Your next action should follow the unresolved question: return to one passage, consult public credits for an attribution question, or leave the interpretation explicitly personal.\nThe downloadable worksheet is deliberately plain. Keep it locally, remove identifying details before sharing it, and retain your earlier version when you revise a claim. A useful result may be a more modest sentence. That is progress when the sentence becomes easier to explain, revisit, and correct.",
      "date_published": "2026-09-13T06:30:04.599307+00:00",
      "id": "https://publishing.oyotta.org/research/practice/a-listening-comparison-you-can-repeat/",
      "title": "A listening comparison you can repeat",
      "url": "https://publishing.oyotta.org/research/practice/a-listening-comparison-you-can-repeat/"
    },
    {
      "_oyotta": {
        "object_id": "STUDY:build-an-archive-that-can-correct-itself"
      },
      "content_text": "An archive is easier to use when each item answers a question. Before saving a page, image, quotation or note, write one sentence about why you may need it again. “Useful later” postpones the decision. “Records the public description I used when writing this comparison” identifies both the role and the limit of the item. This method is intended for your own notes and material you have permission to retain; it does not grant rights to redistribute another person’s work.\nFor an OYOTTA reading project, begin with the public archive-and-memory collection or a public book sample. Save the canonical link and your own notes. Keep full paid editions within the access terms under which you received them. A public link and a short description are often sufficient for a shared index; a complete copied file is not always necessary.\n\nUse a stable local identifier such as NOTE-001 for the item. Store its source URL separately. Store the date you retrieved or consulted it separately again. These fields answer different questions: which item you mean, where you found it, and which encounter your note describes. A renamed file should not silently become a new source, and two visits to one URL should not be assumed to contain identical material.\nA minimal record contains an identifier, displayed title, source URL, consultation date, your description, and the item’s rights or sharing limitation when known. If you retain a permitted file, add its filename and a checksum. A checksum can identify a byte-level change; it cannot tell you that the content is true, that the publisher approved your interpretation, or that the copy was lawful to distribute. Write those limitations in the record rather than expecting a technical field to imply them.\n\nSuppose your note calls a passage a conclusion, and a later reading shows that another section follows it. Do not erase the earlier note without a trace. Add a correction explaining the original description, the new description, the source that prompted the change, and the date. Mark which description should be used now. The earlier version remains useful for understanding why a draft or comparison contained the mistake.\nThis is an invented example of a correction process, not a claim that a particular OYOTTA page contains an error. Your correction can be brief. “I previously described this as the ending; it is followed by another section in the linked edition” is more informative than “updated for accuracy.” Avoid making the explanation larger than the evidence supports. If the editions differ, record that possibility instead of declaring one universally correct.\n\nOne route is chronological: the order in which you collected and revised records. Another is thematic: the questions the records help answer. Keep both. A folder named “return” may be useful for a theme, but it cannot replace dates when you need to reconstruct a revision. Conversely, a list sorted only by date may hide a useful connection between distant records.\nUse a small number of explicit relationship labels such as “compares with,” “quotes,” “corrects,” and “public sample of.” Each relation should name its two endpoints. A shared word in two titles is a search clue, not proof of a relationship or collaboration. If a relationship is your interpretation, label it that way. This keeps a personal discovery tool from becoming an unsupported catalogue of facts.\n\nChoose one paragraph from your latest draft. Starting only from its source identifier, try to recover the original public link, the note used in the draft, and any later correction. Record the steps that failed. Repair the missing connection before collecting another batch. This small exercise tests whether your archive supports the actual work you want it to do. It does not require a new platform or a complicated database.\nExport the index as CSV and keep a plain-text description of its fields. Store an additional copy in a separate location you control, with appropriate privacy protection. Open the exported copy and repeat the recovery exercise. A backup that has never been opened is an untested recovery option. End with one concrete improvement: a missing date, an ambiguous relationship label, a broken local filename, or a correction that was not linked back to the draft. The value of the archive is in what it lets you recover and explain.",
      "date_published": "2026-09-13T06:30:04.342174+00:00",
      "id": "https://publishing.oyotta.org/research/practice/build-an-archive-that-can-correct-itself/",
      "title": "Build an archive that can correct itself",
      "url": "https://publishing.oyotta.org/research/practice/build-an-archive-that-can-correct-itself/"
    },
    {
      "_oyotta": {
        "object_id": "STUDY:measure-a-creative-practice-without-chasing-counts"
      },
      "content_text": "A useful measure helps you choose what to do next. If your question is how to finish a draft, counting ideas may reward the very activity that delays completion. If your question is how to make a passage clearer, counting total words may hide the improvement. Write the decision first: which of two working routines should I repeat next week, or which unresolved part of this project deserves the next session?\nUse the OYOTTA creative-practice collection as a reading starting point, then define an experiment in your own work. This is a planning method, not a promise of productivity, income, wellbeing or artistic success. A good experiment can reveal that your current measure is unhelpful. That result is worth preserving rather than disguising as a win.\n\nAn attempt is something you do: sit down for a scheduled session, revise one paragraph, sketch two alternatives, or record a short passage. An outcome is the observable result you care about: the paragraph answers the stated question, the sketch communicates the intended contrast, or the passage is ready for a named next step. Decide what would count before you begin. “Worked hard” does not establish that the outcome occurred.\nFor a writing exercise, you might define completion as a paragraph containing a claim, its supporting example, and a sentence that states the example’s limit. That is a proposed editorial criterion. It is not a universal rule for all writing. Use a criterion suited to the work and keep it stable long enough to compare attempts. If you change it, record the change and begin a new comparison rather than combining incompatible results.\n\nRecord how many sessions were attempted as well as how many produced the defined outcome. Three completed passages from four attempts describe a different situation from three completed passages from twenty attempts. Also record time spent, interruptions, and whether you were starting or revising. These are possible explanatory conditions, not excuses to delete difficult sessions.\nAn average can conceal a useful pattern. Five minutes on one day and fifty-five on another average thirty, although neither session lasted thirty minutes. Keep the individual rows alongside any average. Group similar conditions only when you have enough comparable observations to make the grouping useful. A weekday label alone does not establish a seasonal effect. Differences may reflect workload, task difficulty or chance.\n\nChoose a change you can reverse: write the question before drafting, prepare the source notes in advance, or stop a session after one defined deliverable. Describe your expectation and how long you will try it. Avoid changing your tools, schedule, project and completion criterion at the same time; if the result changes, you will have little basis for deciding which change to retain.\nCompare the actual rows after the trial period. A small personal experiment can guide your next choice, but it usually cannot establish that the change caused the result. If the new routine coincided with easier work or fewer interruptions, retain those explanations. Do not remove failed attempts merely because they make the average less attractive. Instead, ask whether the routine remains practical under the conditions in which you actually work.\n\nLook at where attempts stopped. If starting was easy but revision repeatedly stalled, adding more idea-generation sessions is unlikely to answer the observed problem. Try a revision-focused step: identify the weakest claim, locate one relevant example, or ask a reader to describe what they understood. Use consent when involving another person and do not invent their feedback.\nFinish your record with one of three decisions: repeat the method, revise one element, or stop using this measure because it does not inform the work. Add the evidence behind that decision and a remaining uncertainty. The worksheet leaves space for both. Over time, this creates a history of decisions rather than a scoreboard. The aim is a practice you can understand and adjust, with room for work whose value is not captured by the current metric.",
      "date_published": "2026-09-13T06:30:04.048735+00:00",
      "id": "https://publishing.oyotta.org/research/practice/measure-a-creative-practice-without-chasing-counts/",
      "title": "Measure a creative practice without chasing counts",
      "url": "https://publishing.oyotta.org/research/practice/measure-a-creative-practice-without-chasing-counts/"
    },
    {
      "_oyotta": {
        "object_id": "STUDY:build-a-release-packet-that-survives-a-broken-link"
      },
      "content_text": "Start with one work you can describe accurately. A release packet is a small collection of files that helps another person identify that work, understand its context and find the current authorized version. It does not need to contain every asset. If you cannot redistribute an audio recording or photograph, preserve its identifier, descriptive metadata and canonical reference instead of copying the asset. The exercise below concerns information organization; a packet does not grant permission to distribute a work.\nWrite a one-sentence purpose before choosing a format: for example, another person should be able to identify the publication and distinguish its sample from its complete edition. Then name three things that must remain understandable without opening a website: the title, the version and the relationship between the included items. Separate those requirements from conveniences such as a streaming player. This distinction gives you a meaningful failure test. A player can disappear while the packet still explains what it pointed to. Avoid calling an incomplete packet a complete archive.\n\nMake a spreadsheet with these columns: item_id, title, kind, version, canonical_url, local_path, relationship, access_status and checked_date. Give each item an identifier that remains stable when its filename changes. Use a separate row for a book sample, a music reference, a photograph and a transcript. In relationship, state only what you know: illustrates item A, sample of item B, or accompanied this particular edition. Do not turn proximity on a page into a production credit.\nFor access_status, use precise labels such as public reference, included with permission, restricted edition or unknown. An empty local_path means the packet contains a reference rather than the underlying file. Keep unknown values visible. Guessing an artist credit makes the table look complete while reducing its usefulness. Save the spreadsheet as CSV and include a plain-text explanation of the columns. Open that CSV in a text editor once: check that titles containing commas or line breaks remain one field, and that non-English characters survive the export. Keep the original spreadsheet too if it contains useful formatting.\n\nImagine a hypothetical packet with three invented items: publication P1, image I1 and audio reference A1. P1 has a locally included public sample; I1 has a locally included image that you are authorized to share; A1 has a canonical listening reference but no copied recording. These labels describe an exercise, not actual OYOTTA releases or permissions. Write the relationships explicitly: I1 illustrates the sample of P1, while A1 is a listening reference selected for this exercise.\nNow pretend the listening service is unavailable. Ask a second person to use only the packet to identify which item is missing, which items remain usable and where they would look for an updated reference. Do not repair the packet while they work. Record each question they have. If they mistake the sample for the full publication, improve access_status and the plain-text introduction. If they cannot distinguish a broken link from a missing local file, improve local_path. The useful result is a specific information defect you can repair, not a score claiming that the work itself improved.\n\nFor each included file, record its byte size and, if your tools support it, a SHA-256 checksum in a separate checksum table keyed by item_id and version. A checksum lets you compare a later copy with the recorded bytes. It cannot establish who created the work, whether a credit is true or whether you have permission to distribute it. Keep those questions in the manifest and source notes. Do not substitute a technical match for editorial checking.\nCopy the packet to another location, open the files from that copy, and compare the checksums. Then alter a disposable copy of one text file and confirm that your comparison detects the change. Never perform this experiment on your only copy. If the check fails to detect the alteration, repair the procedure before relying on it. Finally, ask someone to follow one relationship in the manifest back to its stated source. This tests a different failure mode: intact files can still carry an unsupported relationship. Record the integrity test and the source check separately.\n\nPut a short README beside the manifest. Explain the packet's purpose, which files are samples, which references require online access, what remains unknown and where corrections belong. Include the packet version and the date of the last real check. Change that date when you perform the check, not merely when an automated timer runs. Preserve the previous manifest when you revise a relationship so that a later reader can understand what changed.\nChoose a bounded maintenance rule: inspect the canonical references when a new edition is released, and after a reader reports a broken reference. Decide in advance what requires a new packet version. A corrected credit or replaced asset usually deserves a clear change note; a differently formatted spreadsheet may leave the underlying information unchanged. Keep these distinctions explicit rather than generating a new edition for every cosmetic alteration. End the exercise by listing one unresolved dependency and one next action. A useful packet makes its limitations recoverable. It does not promise permanence, prove popularity or replace the original work.",
      "date_published": "2026-09-13T08:00:07.782443+00:00",
      "id": "https://publishing.oyotta.org/research/practice/build-a-release-packet-that-survives-a-broken-link/",
      "title": "Build a release packet that survives a broken link",
      "url": "https://publishing.oyotta.org/research/practice/build-a-release-packet-that-survives-a-broken-link/"
    }
  ],
  "title": "OYOTTA Practical Studies",
  "version": "https://jsonfeed.org/version/1.1"
}