Six steps turn a raw, high-volume coparenting record into a de-identified, source-linked, professional-review-ready package. Below: what happens at each step, why, and — just as important — an honest account of what the step cannot claim.
Each step takes a defined thing in and hands a defined thing on. Select a step to open it: what it is given, what it produces, and what it does not claim.
Texts, co-parenting-app logs, and email are collected from the sources counsel provides and normalized into a single working record, preserving each entry's original sender, timestamp, and platform.
What comes out of this step is not a deliverable on its own. It is the one working record every later step reads from, which is why the three facts that let a reader place an entry — who wrote it, when, and on what platform — are carried forward from the beginning rather than reconstructed at the end.
Names and other identifying details are replaced with consistent, opaque tokens (e.g. Parent A / Parent B) before the record is chronologized — de-identification happens first, not as a final scrub.
The position in the sequence is the point. Because it runs before the record is put in order, everything that follows — the ordering, the numbering, the packaging — is done on a record that already reads as Parent A and Parent B. The same person is always the same token, so a reader can follow one party across five years of entries without a name appearing.
Every entry is placed in a verbatim, timestamp-ordered chronology. Each line binds back to its exact source record — nothing is summarized or paraphrased at this layer.
Chronology is the spine of the package. Entries from different sources interleave into a single sequence, so an exchange that moves from a co-parenting app to email to text reads as one thread rather than three. Every line stays in the words it was written in, and carries a pointer to the record it came from, so a reader who doubts a line can go and look at its source.
Each exhibit carries the SHA-256 content hash of the source record it came from, captured at intake — a cryptographic fingerprint of the original. The finished package also ships with a manifest listing a SHA-256 for every delivered file and a single fingerprint over the bundle as a whole, so accidental corruption or any single-file edit is detectable. Independent verification against deliberate alteration requires comparing that bundle fingerprint to a copy held outside the package; we will provide it on request.
A fingerprint here is a short string derived from a file's contents: change the contents, and the string changes. Recording it at intake is what lets a reader later ask whether the thing in front of them is the thing that came in — and answer that question themselves rather than take our word for it.
Exhibits are numbered and auto-indexed the way a court filing expects; child-safety and welfare-relevant topics are surfaced by literal-term recall for human review, not scored or ranked.
Numbering is what makes the package citable. Once an entry carries a number, counsel can point to it in a brief, in a deposition, or at a hearing, and everyone is looking at the same line. The index lists those numbers in order, so a reader can reach a date or a party's entries without paging through the whole set.
The finished package — Record, Dashboard, and Exhibits — is delivered through the Professional Portal, which runs on Progress ShareFile, never by email. Two-factor sign-in and per-matter isolation are configured on our ShareFile account; we have not yet completed our own end-to-end verification of those settings, so we describe them as configured rather than proven — see Security for exactly how far we have taken it.
Everything above — the ordering, the numbering, the fingerprints — exists so that what arrives can be examined by someone who was not there when it was built. What that examination can and cannot rest on is set out in full on the Security page.
The third column is the page's own language, unchanged. The row for the step you have open is marked.
| Step | What goes in | What comes out | What this step does not claim |
|---|---|---|---|
| 01Intake | Message exports, app logs, and email threads, in the formats counsel provides | One working record; each entry keeps its original sender, timestamp, and platform | Intake normalizes those formats — scanned images and screenshots are not machine-read; we refuse to guess at text rather than present a guess as a source record, so those are handled with you directly. |
| 02De-identify | The working record from step 01 | The same record, with consistent opaque tokens standing in for identities | De-identification is thorough, not infallible — a human review pass remains part of every delivery. |
| 03Chronologize | The de-identified working record | A verbatim, timestamp-ordered chronology, each line bound to its source record | Each line binds back to its exact source record — nothing is summarized or paraphrased at this layer. |
| 04Hash-seal | The chronology and the source records behind it | A fingerprint per source record, a manifest, and one fingerprint over the bundle | Independent verification against deliberate alteration requires comparing that bundle fingerprint to a copy held outside the package; we will provide it on request. |
| 05Bates-number | The source-linked chronology | Numbered exhibits, an index, and topics surfaced for human review | Literal-term recall surfaces likely-relevant entries; it is not an exhaustive review and does not replace counsel reading the full chronology. |
| 06Deliver | The finished package and its manifest | Delivered through the Professional Portal, in a space set up for that matter | Two-factor sign-in and per-matter isolation are configured on our ShareFile account; we have not yet completed our own end-to-end verification of those settings, so we describe them as configured rather than proven — see Security for exactly how far we have taken it. |
The record is normalized, tagged, and structured by established natural-language-processing components that organize and label it for human review. None of their output is published as a score, rating, or assessment of a person, and none of it appears in a deliverable as a finding.
The Pyra Report makes no determinations, scores, risk ratings, or parenting assessments, and it does not rank a parent. It organizes the record — it does not adjudicate it.
Outputs are litigation-support work product, not evidence, legal advice, or a custody recommendation. Literal-term recall surfaces likely-relevant entries for human review; it does not certify that every relevant entry has been found, and it is never a substitute for counsel reading the full record.
A matter like this typically arrives as a mix of exported app logs and forwarded email threads. Intake normalizes those formats — scanned images and screenshots are not machine-read; we refuse to guess at text rather than present a guess as a source record, so those are handled with you directly. De-identification runs before anything is chronologized, and the finished Record, Dashboard, and Exhibit set are delivered through the Portal, in a space set up for that matter; as above, those Portal settings are configured rather than independently verified by us. See the full package →