Tool & guide

Problems With Delaware Statutory Trust: Investor Issue Resolution Log

Investor Issue Resolution Log

Users document an administrative or reporting issue, its source, responsible contacts, responses, and resolution status. The log separates facts from assumptions and helps track outstanding follow-up.

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 a tool for tracking an investor's administrative or reporting questions about a DST. It keeps reported facts, sources, assumptions, contacts, responses, and chosen follow-up dates in separate fields. Each saved update becomes part of the issue's history, so a later conclusion does not erase an earlier question. The tool organizes your entries without verifying a complaint, sending a message, or deciding that a problem has been resolved.

Table of Contents

Define the DST Issue Before Tracking It

Start with one offering label and a clear review scope. Use a non-sensitive name rather than an account number. A scope such as “questions about the September report and payment records” tells a later reader what this log covers. It does not imply that you reviewed every aspect of the investment.

Give each issue a short title that identifies one question. “September report reference” is more useful than “Bad service.” The first can be linked to a document and a request. The second mixes a broad judgment with an unclear event. A precise title also helps prevent several people from tracking the same matter under different names.

Choose a category: report or document, payment record, account administration, or other. These are filing labels. They do not assign fault, identify a legal claim, or set the severity of the matter. A missing report link may be easy to fix, but a question about the report's contents can remain after the link works.

The offering label and scope lock after the first issue is saved. The issue title, category, and first-noticed date also remain fixed. This keeps earlier entries tied to the same question. If an identity is wrong, record the correction in a closure note and create a distinct corrected issue, or begin a new log after exporting what you need.

Separate Reported Facts From Assumptions

The reported-facts field is your statement about what you observed or were told. Keep it specific. You might write that two statements display different labels for a payment, or that a supplied report link would not open on a stated date. That is different from concluding why the discrepancy occurred.

Put possible explanations in the assumptions field. For example, “The figures may cover different periods; this has not been confirmed.” That wording preserves the open question. Do not turn a guess into a factual finding simply because it offers a plausible explanation for the problem.

A source field can identify the record behind the facts. Include a document name, period, page, message date, or another useful locator. The tool does not follow links, upload files, read attachments, or check authenticity. A filled source field means only that text was entered. Keep the actual evidence in a separate, appropriate place.

The tool permits an issue without a fact-source reference, then flags that missing field in the result. This allows you to log a question before all records arrive. The gap stays visible. It does not prevent you from acting outside the tool or turn an unsupported entry into verified evidence.

When new information changes the facts, append an update. Describe what changed and why. The old entry stays in the saved history. That lets another reader distinguish an initial report from a later correction instead of assuming the corrected detail was known from the start.

Identify the Contact and the Response Source

Enter the role or team that you expect to contact. A non-sensitive reference such as “issuer investor services” may be enough. Record a particular person only when that detail is useful and appropriate. The field does not send a request, verify an address, or prove that the named party accepted responsibility.

Match the request to the actual role. A broker may help locate a record without being its author. An issuer may explain a report, while a tax professional addresses how a figure applies to the investor. The SEC's relationship-summary guidance explains that services depend on the agreement with the broker or adviser. Do not infer a duty from the name entered in this log. SEC relationship-summary guidance.

Keep the response summary separate from its source. “Received an explanation of the reporting period” describes the response. “Written reply dated October 8” identifies the evidence. If a response is entered without its source, the result flags the missing reference. A response can still leave the main question unanswered.

Read a receipt notice differently from a substantive answer. An automated message may establish that a request was received, but it may not address the discrepancy. Describe it accurately in the response field and keep the issue open when the recorded question remains unresolved. The tool does not judge how useful the response was.

Choose a Status That Describes the Current Record

Five statuses describe the state you are recording. Open—not contacted means the question has been logged without a recorded outreach step. Awaiting response means you are waiting for an answer. Response received—unresolved means an answer exists but the question remains open. All three require a next action.

Resolved—user recorded is a stronger personal conclusion. It requires a response summary, a response-source reference, resolution evidence, and a closure note. These fields make the conclusion easier to inspect. They do not cause the tool to check a document or certify that the response is accurate.

Closed without resolution is different. It lets you record that this work item is being closed without claiming the question was solved. A closure note is required. Explain whether the matter moved to another process, was duplicated elsewhere, or remains unanswered for another reason. Closing the row does not waive rights or prove the issue was unimportant.

Both closed statuses require the follow-up date to be cleared. That removes the issue from this log's active follow-up queue. You may still need action outside the log. Record that context in the closure note. Do not close a matter solely to remove a past-date flag from the screen.

Each status is a user-entered description, not a legal or factual finding. Missing information can remain even in a resolved row. For example, a contact role may be absent. The tool shows those field gaps separately so the status does not hide them.

Set Dates and Read the Follow-Up Calendar

The review cutoff states the date of this view. It cannot be after the current date in UTC. The first-noticed date and all saved entry dates must fall on or before the cutoff. Entry dates cannot precede first notice or move backward within one issue's history. Same-day updates are allowed and retain their saved order.

The follow-up date is a date you choose for the next step. It must be on or after the date of that entry, but it may be after the review cutoff. That lets the log show a future planned action. Dates must be real calendar dates between 1900 and 2200. An invalid date is rejected while saved issues remain unchanged.

An open issue is past its chosen follow-up date only when that date is earlier than the cutoff. Equality means due at cutoff. A later date means future follow-up. A blank date is shown as missing. The tool does not guess a deadline or treat a blank as permission to wait indefinitely.

Calendar counts include weekends and holidays. For open issues, days since first notice runs to the cutoff. For closed issues, days to the latest closure entry runs to that entry's date. These are elapsed-day counts: first notice on October 1 and a cutoff of October 16 gives fifteen days, not sixteen.

The counts do not measure a provider's response time. An issue may have been noticed before anyone contacted the provider, and a closure entry may be saved after the real-world event. There is no average service score. Chosen reminders are not legal deadlines, complaint-filing dates, or agreed service standards. The tool does not calculate or extend any such deadline.

Preserve Changes and Reopened Issues

Use Append entry for the issue you want to update. The current fields fill the form, while the fixed identity stays locked. Change the entry date and the details that now apply. Saving adds another entry; it does not replace the earlier one. The tool allows twenty issues and ten saved entries for each.

To reopen an issue, choose an open status, enter the next action, and clear the closure note and resolution-evidence fields. The earlier closure remains in history. This separates the old conclusion from the new open question. A currently open issue with a prior closed entry is marked as reopened.

Reopening does not reset the first-noticed date. The open elapsed-day count therefore includes the whole span since first notice, including any period when the issue was closed. It is not a measure of uninterrupted waiting. Read the history before drawing conclusions from the number.

A failed save preserves the current form and previously saved issues. Correct the stated problem, then save again. A save with no changed entry fields is rejected. If you only opened a saved issue to read it, cancel the unsaved revision to return to the saved log.

There is no deletion or archive control for an individual saved issue. A correction can be explained in a new entry. Starting a new log clears the entire current working record after an in-page confirmation. Export first if you need to preserve it. Canceling that confirmation keeps both saved and unsaved work.

Work Through the Fictional Example

The example uses the invented Alder Point DST. No real provider, communication, or document is represented. It contains three issues and three entries at an October 16, 2026 cutoff. Two issues are open, and one has a user-recorded resolved status. The example has no listed field gaps, which does not make its fictional evidence verified.

The first issue concerns an unavailable September report reference. It was first noticed October 1 and has a chosen follow-up date of October 10. At the cutoff, it is fifteen calendar days since first notice and six days past the chosen follow-up. Its assumed cause remains unconfirmed in a separate field.

The second issue concerns different labels for one payment. It was first noticed October 5. An October 8 response explains the period but leaves the label question unresolved. The chosen follow-up is October 16, so it is due at cutoff. Eleven days have elapsed since first notice. A response has not been treated as a resolution.

The third issue concerns a mailing-label correction. First notice is October 3, and the closure entry is October 9. The displayed count is six days to that entry. The response source and resolution evidence are fictional teaching references. The tool does not establish the date on which a real provider finished work.

Try reopening the third issue with a later date and a specific next action. Clear the closure fields before saving. The log will retain the original resolved entry and add the open entry. If you use October 16 as the cutoff, the reopened issue has thirteen days since first notice. That count includes the earlier closed period.

Read Counts Without Turning Them Into Ratings

The summary counts saved issues, entries, open matters, recorded resolutions, and closures without resolution. It also reports currently reopened issues, past and due follow-ups, missing follow-up dates, and issues with listed field gaps. Those counts describe this file's contents only.

A large number of entries may show careful recordkeeping rather than poor service. A short log may omit problems. Different users may split one concern into several issues or combine several concerns into one. These differences make the counts unsuitable as a sponsor or broker ranking.

Use the display filter to focus on open, closed, or past-follow-up issues. Filtering changes only the visible result. The full summary and both exports still include every saved issue and its history. This prevents an open-only view from silently deleting the context of earlier closures.

The tool does not assess claim severity, damages, fault, or the truth of a response. It also does not sort matters by legal urgency. Read the details, source limits, and next actions. A single unresolved issue may need more attention than many closed rows.

Export the Full Log and Keep the Evidence

Save or clear the current entry before building the result. Changing an input clears the old output and disables downloads. That prevents a result made before an edit from being exported as though it reflected the latest form. Correcting an invalid cutoff and building again restores a result from the retained saved issues.

Download JSON for structured data or text for a readable record. Both include all saved issues, all entries, current details, summary counts, and the scope. Neither contains the actual documents named in the source fields. There is no import feature, and closing or reloading the page loses the working state.

The saved log is limited to 200,000 UTF-8 bytes, with a one-MiB limit on each export. Long notes and repeated entries may reach a size limit before the issue count does. A rejected entry does not partially replace the saved log. Keep a separate work file if the case needs more space.

Protect the exports as you would other investment records. Avoid passwords, banking instructions, and sensitive account identifiers. The SEC's April 23, 2026 online-account guidance discusses care with personal financial information and cloud storage policies. A plain-text reference in this tool does not provide secure document storage. SEC online-account guidance.

Use the Log Within a Wider Resolution Process

Use a clear entry to support a specific request outside the tool. Identify the discrepancy, the source, and the answer or correction sought. Keep the reply and any revised record with the issue's evidence. Do not describe a request as sent unless someone actually sent it through an appropriate channel.

A private log is not a complaint filing. The SEC's investor-complaints bulletin explains its complaint process and other dispute routes. It also states that the SEC cannot serve as an investor's attorney or personal representative. This tool neither chooses a route nor submits information to any firm or regulator. SEC complaints bulletin, updated September 8, 2026.

Keep a dispute's next steps tied to qualified advice and the actual facts. The calendar is an organizing aid. Its follow-up labels do not tell you how long to wait, whether a claim has merit, or which person is legally responsible. The most useful result is a record that another authorized reader can understand and check.

Frequently Asked Questions

Does saving an issue send a complaint or contact the sponsor?

No. The page does not send messages, file complaints, contact providers, or create alerts. Contact and response fields are manual references. If you take action outside the tool, record what actually happened and keep the supporting evidence separately.

Does resolved status prove the issue was fixed?

No. It records your conclusion and requires explanatory fields. The tool checks whether those fields contain text; it does not inspect the response or resolution evidence. Another reader still needs to assess whether the recorded outcome answers the original question.

Can I keep an issue open after receiving a response?

Yes. Response received—unresolved is an open status. It requires a response summary and a next action. The response source may be entered or left as a visible gap. An acknowledgment or partial answer should not automatically become a recorded resolution.

No. They compare your chosen follow-up date with the review cutoff using calendar days. They are not filing limits, contractual deadlines, or service guarantees. Do not rely on this tool to establish, extend, or monitor a legal deadline.

What happens when I reopen a closed issue?

A new open entry is appended, and the earlier closure stays in history. The tool marks the currently open issue as reopened. Its elapsed count starts at the original first-noticed date, including any closed period. Clear the new entry's closure fields and record a next action.

Can I resume the log from a downloaded JSON file?

No import is provided. The export preserves a record for a person or another suitable system to read. Keep the page open while working and download before leaving. Reloading clears the working state, and the actual documents referenced are never included in the download.

About Sequoia Research

Sequoia Research, LLC provides independent research on DSTs and other real estate investment offerings. This educational library helps readers examine source materials, understand assumptions, and prepare better questions for their investment, tax, and legal professionals.

Sources