Tool & guide

Delaware Statutory Trust Horror Stories: Duplicate-Incident Finder

By Sequoia ResearchPublished Read as Markdown

Duplicate-Incident Finder

Users submit source references describing investment incidents. The tool groups possible duplicates using verified trust, entity, property, and event identifiers, leaving uncertain matches for review.

For an export, select Download in the tool, then Save file when it appears below. Your entries stay in your browser.

What Is This Article About?

This guide explains how to compare reports that may describe the same DST investment event. The tool uses exact identifiers that you enter and mark as checked against a source. It keeps conflicting details visible and leaves every saved record intact. A fictional example shows why six reports, six matching pairs, and two groups do not establish a count of separate incidents.

Table of Contents

What the Duplicate-Incident Finder Does

The tool finds exact links among the source records you supply. It can bring two reports together for review when they share a checked trust, entity, property, or event identifier. It does not decide whether an event occurred, whether a source is true, or whether someone acted improperly.

A search for Delaware statutory trust horror stories can lead to a pile of pages. The page count alone says little about the number of underlying events. An investor letter, a later article, and a summary of that article may all refer to one payment change. One long article may also discuss several events.

Treat a saved row as one source reference about one defined event. If a document discusses three separate events, create three clearly labeled rows. Keep the same document reference, but give each row its own event details and page location. Do not squeeze unrelated dates into one occurrence-date field.

The output has three units: source records, candidate pairs, and possible event/context groups. Each answers a different question. Records show what you entered. Pairs show where two records share at least one checked identifier. Groups collect records with the same checked event key and one matching context key. None is a verified incident total.

The SEC notes that private placements can offer less disclosure than registered offerings. A small public file therefore cannot establish a complete history by itself. This is a reason to define the limits of your search, rather than infer an uneventful history from missing reports. See the SEC's private-placement bulletin, updated in September 2026.

Prepare Your DST Incident Sources

Start with a review label that states the question and scope. “Willow Brook payment-change references through October 17” is more useful than “bad DSTs.” The first label identifies a subject and cutoff. The second risks treating unrelated results as one set.

Choose a cutoff no later than today in UTC. UTC is the common world time used by this tool. It may be one calendar day ahead of your local date. Source issue dates and event dates cannot fall after the cutoff. Blank dates remain unknown; the tool does not fill them from page titles.

Enter a source title, a URL or document name, and a page or section when available. A URL is a reference only. The tool does not open it, inspect its content, or test whether it still works. Open the underlying material yourself before marking the source as read.

Keep the issue date separate from the event date. A letter issued September 15 might discuss a payment change that took effect September 10. A later article might repeat that account on September 25. Those are three different dates serving different roles. Enter the event occurrence date only when the source supports that meaning.

Use the notes field for unresolved scope. For example, write that one date is described as a notice date while another appears to be an effective date. Do not select a convenient date merely to make two rows match. The notes preserve context for the next reader, although the matching rules do not interpret them.

Choose a listed event type, such as a distribution change, property sale, loan event, operating event, or legal proceeding. Use Unknown when the type is unclear. Use Other with a precise note when the listed types do not fit. Sharing the broad label Other does not prove that two events have the same nature.

Enter Trust, Entity, Property, and Event Identifiers

Each record has four separate identifier areas. A trust identifier refers to the particular trust. An entity identifier can refer to a relevant legal company. A property identifier points to the asset. An event identifier points to the specific notice, case, or event record under review.

Supply both the identifier system and its exact value. The system tells a reader where the value has meaning. A local parcel number needs its county or other registry scope. A case number needs the court or forum. An issuer's event code needs that issuer's scope. “Registry” or “case number” alone may be too vague for sound research.

Do not use the same general sponsor name as an identifier for every trust it manages. Shared branding can be relevant context, but it is not proof that two legal issuers are one trust. The tool cannot correct an identity mistake that you enter with confidence.

An identifier enters matching only when you check its confirmation box. A checked identifier also requires an opened-source checkbox, a system, a value, and an evidence reference. State where you found it, such as a document cover, notice heading, or case caption. These requirements record your work; they do not authenticate the source.

You may save an unconfirmed identifier with its box unchecked. Its text remains in the record and export, but it does not create matches or conflicts. The summary counts these excluded entries so you can return to them later. Unchecked does not mean false. It means the tool has no permission to rely on that entry for matching.

The system name ignores letter case and extra spaces. Identifier values ignore surrounding spaces and collapse repeated internal spaces, but preserve case, punctuation, and leading zeros. Thus “ID 007” differs from “ID 7” and “id 007.” Check the source before correcting a spelling difference. There is no alias list or fuzzy name search.

How the Matching Rules Work

Two records become a candidate pair when they share at least one exact checked identifier within the same kind. A property code is compared with property codes, never with event codes. Values from different entered systems are not treated as the same key.

The tool assigns each candidate pair one of four labels:

Pair label What produces it
Shared identifiers with conflicts A shared key exists, but another checked value differs in the same system, or known event dates or types differ.
Event and context match A checked event key and at least one checked trust, entity, or property key match, without a listed conflict.
Context, date and type match A checked context key matches, both event dates are known and equal, and both types are the same non-Unknown choice.
Shared identifier only At least one checked key matches, but the stronger conditions above are absent.

Conflicts take priority. Two rows with the same event code still receive the conflict label when their known event dates differ. That prevents a strong-looking identifier from hiding a dispute in the entered facts.

Missing details appear as gaps. The tool flags unknown event dates, unknown types, missing issue dates, and missing shared event or context keys where applicable. An event-and-context pair can still have an unknown date. Its label describes the identifiers that match, not a complete factual review.

A possible group needs both a shared checked event key and one shared checked context key. Different context kinds can produce overlapping groups. A trust-based group and a property-based group may contain the same three records. Adding their member counts would count those records twice.

Matching does not spread through a chain. If A shares a trust key with B, and B shares a property key with C, A and C do not become a candidate pair without their own shared key. The tool also never combines records, deletes duplicates, or replaces a conflict with a preferred version.

Read the Fictional Willow Brook Example

Select Load fictional example, confirm the change, and then select Find matching references. Every name, code, date, and source in this example is invented. It demonstrates the method and makes no claim about a real sponsor or offering.

The six records have these features:

Record Entered evidence
R1 Checked trust WB-01, property PAR-4, and event EV-7; September 10 distribution change.
R2 The same checked keys, date, and type as R1, with a different source reference.
R3 The same checked keys, but a September 11 event date; its source reference is exactly R1's reference.
R4 The same checked trust and property, September 10 date, and type; no event key entered.
R5 Different checked trust, property, and event values.
R6 The first three values entered but unchecked; the source is not marked opened.

Six records make 15 possible unordered pairs: six times five, divided by two. The tool finds six candidate pairs among them. R1 with R2 has an event-and-context match. R1 with R4 and R2 with R4 have context, date, and type matches.

Three pairs have conflicts: R1 with R3, R2 with R3, and R3 with R4. Their event dates differ. The tool retains the September 11 entry rather than assume it is a typo. A reader must inspect the documents to learn whether the dates describe different things.

Two possible groups contain R1, R2, and R3. One uses EV-7 with trust WB-01; the other uses EV-7 with property PAR-4. Both retain the conflicting pairs involving R3. These are two ways of grouping the same records, not evidence of two incidents.

R5 and R6 have no candidate. R5 has different checked keys. R6 has three unchecked identifier entries, so those entries are excluded. Their lack of matches does not establish two new events. R6 may match after proper source review, while R5 may contain an identity error that needs correction.

Only one candidate pair has exactly matching source-reference text: R1 and R3. That is a prompt to examine shared origins. Different references in the other pairs do not prove independent reporting. The output cannot infer what one writer copied from another.

Review Conflicts and Shared Source Origins

Work through conflicts before drawing a broader conclusion. First compare the source locations. Then compare the exact subject, date meaning, and identifier scope. Preserve the earlier export if you change a record, because this tool does not keep a revision history.

A conflict can be an entry error, a correction in a later source, or a real disagreement. It can also expose a poor choice of scope. A payment notice and the payment itself may need separate event records even when they concern the same amount. Writing down that distinction can be more useful than forcing a match.

Trace copied accounts to their inputs. If three pages quote one issuer letter, retain the three references but note their shared origin. A later writer may add original interviews or other evidence. Assess those added claims separately. Page count is not a measure of how many independent checks occurred.

FINRA's guidance for member firms recommends careful review of third-party information, including the provider's independence, incentives, and qualifications. It also discusses resolving concerns and inconsistencies in due-diligence work. Those are obligations and practices in the member-firm setting; this small research aid does not satisfy that full review. See FINRA Regulatory Notice 23-08.

The tool has no field that turns an allegation into a finding. Describe a source's status in the note, with support. If a matter changes, check the later document and preserve both versions outside the tool. An event match only connects references; it does not settle the merits of a claim.

Save, Edit, and Export Your Research

Save each finished source record before comparing. An unfinished or open editing form blocks new results until you save or clear that form. Invalid entries remain visible so you can fix them. A rejected save does not replace existing saved records.

Records receive stable IDs. Removing R2 does not rename R3, and the next new record does not reuse R2. This helps keep exported pair references clear. Removal, replacement with the example, and clearing the review require an on-page confirmation. Cancel preserves the current work. Editing inputs cancels a pending confirmation.

Input changes clear stale results and disable exports. Compare again after saving. The pair display filter only changes the visible pair list. Full JSON and text exports still contain all saved records, all groups, all candidate pairs, and records without a candidate. They also state the matching method and limits.

The tool accepts up to 30 records. At that size there are 435 possible pairs. Saved input is limited to 120,000 UTF-8 bytes, and each export is limited to 1 MiB, or 1,048,576 bytes. Accented letters and other characters may use more bytes than plain letters. Long records and repeated pair output can make a full export too large even when saved input fits. The error leaves your saved records in place; shorten entries and compare again.

Nothing is automatically saved between visits. There is no import, account, source upload, or server search in this tool. Export before leaving the page. The export holds your entered references and results, not copies of the source documents. Retain those documents separately where you are authorized to do so.

Use the Results in DST Sponsor Research

Use the output to organize follow-up questions, not to rank sponsors by a raw complaint count. The same sponsor may appear across several legal entities. One property may change hands. One dispute may involve more than one party. Those relationships need source support before they belong in a conclusion.

Keep the time window and collection method beside any summary. “Six source records entered from this file through October 17” is a reproducible statement. “Six verified sponsor failures” is a different claim that this tool cannot support.

Separate the identity review from the financial review. Once records are linked, you may still need cash statements, loan terms, operating reports, or sale records to assess the claimed effect. A confirmed event does not by itself establish the amount lost, the cause, or an investor's whole result.

A useful handoff includes the full export, the source files, unresolved questions, and who will check each question. Preserve uncertainty where the evidence ends. The result should make the next review easier to perform and easier to challenge.

FAQ

Does a match prove that two reports describe one incident?

No. A match identifies shared checked fields in your entries. Review the full sources and event scope before reaching that conclusion. Conflicts remain visible, and even a conflict-free pair can have missing details.

Why are unchecked identifiers ignored?

They may be useful leads, but you have not marked them as checked against an opened source. Their text stays in the record and export. Add support and mark the box only after doing that work.

Can the tool find duplicate stories across the internet?

No. It compares only the saved records you enter. It does not read links, crawl websites, search names, or compare article text. A missed match may reflect different codes, spelling, scope, or missing information.

Why can the same records appear in two groups?

One group can share an event and trust key, while another shares the same event and property key. Groups overlap by design. They must not be added together as a count of incidents or affected investors.

Does a shared source reference prove that one writer copied another?

No. It only means the entered reference text matches after spaces are normalized. Different URLs may still point to the same material, and matching document names may be ambiguous. Inspect the sources and describe what you actually found.

Can I restore the exported JSON into this tool?

No. JSON and text are portable research records for reading or further authorized work. This version has no import feature or saved history. Keep a copy before editing or clearing the review, and retain source documents separately.

About Sequoia Research

Sequoia Research, LLC provides independent research on DSTs and other real estate investment offerings. This library explains how to read investment evidence, compare assumptions, and document unresolved questions. Its educational tools do not assign credit ratings or replace a complete investment review.

Sources