Investigation – Chronology of Events

September 15, 2009

In addition to tracking the persons involved in an investigation, one also needs to track the events that occurred. Indeed, what happened and when and in what sequence are the essential components of any narrative. Thus, tracking events and their relation to one another and to the other facts of the case, including the relevant actors, documents, etc., is critical. The difficulty is that in the course of an investigation, events are revealed out of sequence and divorced from their context. The significance of any particular event isn’t usually apparent on arrival.

Tracking events in an investigation can be done in any number of ways, from the simple to the baroque. I favor the simple at the outset of an investigation because speed is of the essence. Events come quickly from various sources. Just one witness interview can yield dozens of dates and events. One small stack of documents can yield still more. Thus, the goal at the outset is to get each event entered into a tracking system. The hope is that, with the addition of each event, the narrative contours become more apparent.

Tinderbox provides a means to capture these events, to sort them chronologically and allowing the user to assess their relationship to other elements of the case. Tinderbox also allows the user to add events and new facts over time. This enables the user to change the relationship of events to one another as new facts are discovered.

In Tinderbox, I track events by using a prototype (protoEvent) and an agent. The prototype ensures that all my events bear the same characteristics, including a single characteristic by which they can all be retrieved. The agent then collects them and sorts them.

To do this, I ensure that the prototype, which I almost always call protoEvent, contains a few user-defined metadata fields. The first ensures that the events can be sorted effectively. Tinderbox always already tracks the date a note was created, which is fine if you create notes the moment an event occurs (e.g., when recording the fact of a meeting with a client or a phone conversation with opposing counsel). But this is obviously too limited concerning events in the past. Thus, I create a field to track the date the event actually occurred, I usually call this “EventDate”. The second is the boolean field “FuzzyDate,” which shows up as a checkbox to indicate that whether the date is precise or only an approximation. This is important to prevent the impression that the date in the date field is more solid than it would otherwise appear.

To create these fields and add them to the prototype, I first define them in the Attributes window (goto the Window/Attributes menu or hit command+2). The EventDate is a “Date” type attribute. This means that the input will be registered as a formal date. The default value is empty. The FuzzyDate attribute is a “boolean” type attribute. This means that for any note the FuzzyDate attribute will either be true or false. The default value is false because I find I usually have pretty solid dates for events.

Attributes Window Image - Fuzzy Date

Once created, these fields are st as the “Key attributes” for the prototype protoEvent. I do this by viewing the content of the protoEvent note and selecting the EventDate and FuzzyDate attributes from the Key attributes drop-down menu.

protoEvent note showing attributes

Once these fields are added to the prototype, every note based on that prototype will contain those attributes. Moreover, these fields will enable an agent to sort the events in chronological order. More on that below.

In addition to the date-related attributes, I also include an attribute called “Source”. This is a “string” type attribute, meaning that the attribute can collect any text input. I use this field to note who or what informed me about the event (e.g., if the Event is the signing of a contract, did I get the date from the contract itself or from Paul Jones who signed it or from some other source?). This is important information to assess how certain I am of the date and for tracking and verifying data later.

One can use the prototype to set the Color and or a Badge for each Event to ensure that they stand out from People and other notes. In addition, because of the way Tinderbox notes display in outline view, I typically start the Name of each Event note with the date the event occurred.

Small map view showing events

Once the prototype is set up, it is easy to add Events to the case file rapidly. Each note based on the prototype inherits all of the key features, including color, badge-type, and metadata fields. One need only type the Name of the note and add two or three key bits of metadata.

Once the prototype is established, Event notes viewed in map view will appear consistent with one another and distinguishable from from other types of notes. In this way, events close in time can be arranged close in proximity or grouped by theme or other aspect. This is a useful workspace for the arrangement of dated events and other facts.

However, often the most useful way to review a sequence of events is in chronological order. To do this without disturbing the arrangement of the notes in map view is to use an agent keyed to the protoEvent prototype. The agent is created like any other, but instead of having it collect notes based on a text string or a name, I have it search for notes where the prototype=protoEvent and then have the agent sort them by the EventDate metadata field.

Chronology agent dialog box

The output of this agent is a simple list of all of the events in chronological order according to EventDate. Here the usefulness of the date-first naming convention is apparent as the dates of different events can be read in sequence.

Chronology agent outline view

The disadvantage of this kind of listed date chronology is that it compresses the time elapsed between events. All events are equidistant from their predecessors and successors regardless whether they are separated by two days, two months, or two years.

The great advantage of Tinderbox is that the same set of dates can be displayed in different ways simultaneously. Thus, when I wish to view or review the distance between events spatially, I use the map view. The agent’s listed chronology of dates is still available to me even as I move the dates further or closer apart.

Map view showing events and people


On Vacation

August 27, 2009

Apologies for the absence of posts this week. I am on vacation. Regular posting will resume shortly.

Investigation – Building a Cast of Characters

August 17, 2009

Among the initial phases of any case is identifying the persons and entities involved and understanding how they relate to one another and to the issues and events in the case.

This entails (1) identifying (and keeping track of) the people involved; (2) understanding their relationship to one another; and (3) exploring their relationship to the events and other aspects of the case.

I use Tinderbox to keep a running list of every name I encounter in my initial investigation, whether learned from documents or in witness interviews. I also use Tinderbox to track my notes on these people, questions about them and information to obtain. Tinderbox also allows me to display how these people are related (if at all).

Each of these three functions is handled by a separate aspect of Tinderbox.

First, I create a new note for each person or entity I encounter. This is infinitely superior to simply listing each person in a text file or in the text box of a single note.

I use a prototype note to ensure that all of these notes share the same essential characteristics.  (I typically use the convention “protoName” for my prototypes, thus the person prototype is “protoPerson.”)  This way, I can add a badge, color, or otherwise set the appearance of each person note.   I typically put these people into a container, but they could just as easily stay on the top level of my Tinderbox document.

Using map view to show character relationships.

Using map view to show character relationships. The head icon on each note is a badge.

Regardless of where I store these characters, viewing them in map view is very useful for arranging the people in relation to one another. Perhaps two ‘characters’ in the case are married.   Perhaps two others were involved in a key transaction.  In addition, some people will be more important than others.   Once I know this, I can make those notes larger or color them more distinctly or give them a badge to denote their special status.  I typically include adornments within this map view to visually connect people as important or as targets of an investigation or what not.

Of course, often in the course of a case, you want to look over a list of all of the people involved.   Perhaps you’re looking for one person in particular or just want to run through everyone in sequence.   Outline view is the best tool for this job.  While I could simply view the container of characters in outline view for a rudimentary list, this is less useful if there are other note types in the same container (e.g., events, questions, notes about issues, or legal elements to prove) because the list will include all of the notes in that container, not just the people.

It is far more effective to create an agent to collect all of the characters in a separate container.  The advantages are (1) to collect all of the characters regardless of where they are created; (2) to only collect characters (as opposed to questions, issues, etc.); (3) and to sort them without disturbing the organization of the notes in map view.

The settings for a Cast of Characters agent.

The settings for a Cast of Characters agent.

To do this, I create an agent, name it Cast of Characters or something similar, and set the query to collect all of the notes where “Prototype=protoPerson”.   I then set the agent to sort the results by the last name (Sort by = name; last word).

Thus, when I want to see a list of the characters, I simply click on the Cast of Characters agent and open it with a new outline view (under the Views menu item).

Outline view presents a list of all of the people in a case.

Outline view presents a list of all of the people in a case.

Investigation – Start Simply with Just a Few Prototypes and Agents

August 13, 2009

One of the great advantages of Tinderbox is the ability to start quick, to jot notes down, and to add structure and fill in relations incrementally over time.

In this sense, Tinderbox can function like a simple legal pad.  Just start writing notes; it doesn’t matter if dates are intermingled with names of people because you can easily manipulate the notes once they are down.  You don’t need to spend time creating a structure to capture information and the risk your data will ossify is much lower than when using a spreadsheet or table in Microsoft Word.

Still, I have found that there are a few structural elements that I always end up adding to my new case files.  I now typically add these right at the outset.  Doing this first speeds input and helps manage the information quickly.

Initial Investigation: Managing Questions

Investigations are always already about asking and answering questions.  Asking questions is how you get information and each new piece of information generates more questions.  When I have a new question, I want to get it down as fast as possible, but I also want to be able to pull out a list of all the questions I have regardless of where they are in my Tinderbox document.  I do this by using a consistent note-title format and an agent.  Every question gets its own note and every question-note starts with “Q: ” (e.g., “Q: Who are the most important people?”).

Viewing the Questions agent in Outline View gives you a list of all questions.

Viewing the Questions agent in Outline View gives you a list of all questions. The italic note names indicate that these are aliases.

These are all collected by an agent I call (imaginatively) “Questions.”  An agent is a special note that collects aliases of other notes within it.  I create a Questions agent that seeks out every note whose name includes “Q: ”  Because I rarely use the “Q: ” phrase in any context other than a question, this agent is very accurate.  Viewing the questions agent in outline view quickly gives me a list of all of the questions I have raised.

In addition to collecting aliases of notes, agents can also perform actions on the notes it collects.  I like my questions to be a conspicuous, high-visibility yellow in my Tinderbox maps.  I have the Questions agent change the color of every “Q: ” note by setting the agent’s action to “Color=yellow”.

The agent dialog box for the Questions agent

The agent dialog box for the Questions agent.

Thus, once the agent is set up, there is no interruption in the creation of questions.  One does not need even to toggle a checkbox as the note is created; the name creates its nature as a question.

Initial Investigation: Prototypes for People and Events

In starting the investigation phase of any case – whether I’ve had a client come to me with a new problem, whether a formal complaint has been filed against my client, or whether I am trying to determine whether there is a case to pursue – there are a few specific questions that I know I’ll need to answer: (1) who are the key people? and (2) what happened?  These are among the fundamental first questions.

The answers to these questions arise over time.  I typically create two prototypes to help me collect the information I need to address them.  A prototype in Tinderbox is a note with certain characteristics.  Notes based on that prototype inherit those characteristics, including the characteristic of being-based-on-that-prototype.

Thus, I almost always create two prototypes: one for persons and one for events.  I give each a distinct color, sometimes a badge (a symbol in the upper right corner of the note), and then specify a few attributes (i.e., metadata) that I want the notes based on that prototype to carry.

An image of two prototype notes.  The icons on the right side of each are badges.

An image of two prototype notes. The icons on the right side of each are badges.

For the protoPerson prototype, the key bits of metadata to collect are fairly obvious: name, address, contact information, etc.  These are already available in Tinderbox’s list of available attributes.

For the protoEvent prototype, the key info to track is the date of the event.  To track this, I create a new called EventDate.  Once this is captured it is easy to create chronologies and useful lists of dates.  In a later post I will discuss using agents to collect and manage a Cast of Characters and a Chronology.


August 12, 2009

Eastgate’s Tinderbox application is a fascinating, brilliant, and extraordinarily flexible application. By its depth it resists categorization. In fact, there is nothing to which Tinderbox can be compared. It is in part an outliner. It is partly a relational database. Partly a visual mind-mapping something-or-other. It is a tool that does not have an analogue. It is unlike any other piece of software. It is unlike anything physical either.

Perhaps as a result of its nature, and perhaps because its creator is adamantly (and admirably) opposed to telling you how to use it, Tinderbox has a very steep learning curve.  Moreover, I happen to think that Tinderbox users benefit most from seeing how others have used it.  I have learned tons from seeing how others have used Tinderbox.  Hopefully some will find my experiences useful.