Category: Technology, Data & AI

Writing on data modeling, architecture, governance, artificial intelligence, and lessons drawn from four decades in technology.

Party Relationships
We’ve explored who a Party is, the roles a Party can perform, and how those roles change over time.

But knowing who someone is and what they do doesn’t necessarily tell us how they are connected to others.

A Role Is Not the Same as a Relationship

Consider a person who is a manager.

The term Manager may describe a role or responsibility within an organization.

But it does not tell us whom that person manages.

To answer that question, we need a relationship between Parties.

For example:
- Person A manages Person B.
- Person B is managed by Person A.
- Organization A is a subsidiary of Organization B.
- Person C serves as an advisor to Organization A.
These examples describe connections between specific people or organizations.

Relationships Have Meaning and Direction

A Party Relationship describes an association between two Parties within a defined business context.

One way to represent that relationship is to identify:
- From Party: The Party from whose perspective the relationship is described.
- To Party: The Party to which the relationship points.
- Party Relationship Type: The nature of the relationship connecting them.
For example:
- From Party: Jane
- To Party: Robert
- Party Relationship Type: Manages
Together, these tell us that Jane manages Robert.

Looking at the relationship from Robert’s perspective, we would say that Robert is managed by Jane.

The Parties are the same, but the way we describe their relationship depends on its direction.

Business Context Matters

Relationships must also be understood within their business context.

A person may manage employees in one organization while serving as a volunteer in another.

Those relationships have different meanings and responsibilities.

We should not assume that a relationship established in one context automatically applies in another.

Why Does This Matter?

When relationships are treated simply as attributes of a Party, we may lose important information about who is connected to whom.

For example, recording that someone is a manager does not necessarily identify the people they manage.

Similarly, knowing that two organizations are business partners does not explain the nature or direction of their relationship.

Representing relationships explicitly helps businesses understand organizational structures, responsibilities, reporting arrangements, and other connections.

The Key Point

A Party Role describes the capacity in which a Party participates. A Party Relationship describes how one Party is connected to another.

Both concepts matter, but they answer different questions.

Before modeling a business association, ask:

Are we describing what a Party does, or how that Party is connected to another Party?

Understanding the difference helps us build models that represent business relationships more accurately.

Continue Exploring Understanding Data Modeling

This article concludes our introductory seven-part discussion of the Party Model.

Visit the Understanding Data Modeling series index for the other articles and future topics exploring enterprise data modeling.

Return to the Understanding Data Modeling Series Index
November 2, 2026
Roles Change Over Time
In our previous post, we explored how a single Party can perform multiple roles within a business.

But those roles are not necessarily permanent.

A person may become a customer, later accept employment with the same company, and eventually leave that employment while remaining a customer.

The person is still the same individual. What has changed is the role, or combination of roles, that the person performs.

Roles Have a Lifecycle

A Party Role may begin, change, or end without changing the Party’s underlying identity.

Consider someone who:
- Becomes a customer.
- Accepts employment while remaining a customer.
- Leaves employment but continues as a customer.
- Returns as an employee several years later.
The person remains the same, even as their roles change over time.

Depending on the business requirements, the model may need to represent multiple periods during which the same Party performed a particular role.

Why Does Time Matter?

Business systems often need to answer questions about both current and historical activities.
- Who was an employee on a particular date?
- When did an organization become a supplier?
- Was someone acting as a customer, employee, or both when a transaction occurred?
If our model represents only current roles, we may lose the ability to answer these questions accurately.

One common approach is to record when a Party Role becomes effective and, when applicable, when it ends.

The appropriate level of historical detail depends on the business requirements. Not every system needs to preserve the same information.

What Happens When We Get This Wrong?

When identity and role are combined, ending a role may inadvertently remove or obscure information about the Party.

We may also create duplicate records when someone returns to the business in a different capacity.

Both situations make it more difficult to maintain accurate information and reconstruct historical business activities.

The Key Point

A Party’s identity can remain consistent even as its roles change over time.

Separating Party from Party Role allows us to represent changing participation without unnecessarily creating new identities or losing information about existing ones.

Before designing how a role will be represented, ask:

Do we need to know only the Party’s current role, or must we also know when that role was active?

Next in This Series

Party Relationships

In our next post, we’ll examine how people and organizations are connected to one another.

Return to the Understanding Data Modeling Series Index
November 2, 2026
One Party, Many Roles

In the previous posts, we separated who a Party is from what that Party does.

That distinction becomes especially important when one person or organization participates in the business in several ways at the same time.

Consider Maria again.

Maria may be an employee. She may also be a customer. She might volunteer for an event or participate as a member of an organization.

Those activities do not create four Marias.

There is one Party performing multiple roles.

The Party represents Maria’s identity. Her roles describe the different ways she participates in the business.

Different Roles, Different Information

Each of Maria’s roles represents a different business context.

As an employee, the business may need information about her employment. As a customer, it may need information about her customer activity. As a volunteer, it may need information about her participation in the volunteer program.

Each role may require different information. But Maria’s underlying identity does not need to be duplicated each time.

Party Role gives us a way to represent those different ways of participating while keeping them connected to the same Party.

This allows the business to see Maria as one person while still recognizing each of the roles she performs.

Why Does This Matter?

Without that distinction, each business area may see only its own version of Maria.

Human Resources sees an employee. Sales sees a customer. The volunteer program sees a volunteer.

Each view may be correct, but none of them alone represents the whole person.

When those roles are connected to the same Party, the business can recognize that they all refer to Maria while still preserving the information that belongs to each business context.

One Party with many roles gives the business a more complete view without losing the distinctions that make each role meaningful.

What Happens When Roles Change?

A Party can perform several roles at the same time.

But those roles do not necessarily remain the same.

A person may become an employee, later leave that employment, remain a customer, and perhaps take on another role in the future.

The Party remains the same even as its roles change.

Next in This Series

Roles Change Over Time

Return to the Understanding Data Modeling Series Index

November 2, 2026
Why Not Just Call It Entity?

In data modeling, the word entity has a broad meaning.

An entity represents something of interest to the business. Depending on the business and the model, that could include people, organizations, places, things, events, transactions, concepts, and much more.

The word entity may also have a particular meaning within the business itself. An organization may already use the term as part of its established business vocabulary.

So why introduce another term?

Party does not replace the concept of Entity.

It gives us a more specific term for something we need to model.

A Party represents a person or organization whose identity matters to the business.

In that sense, Party gives us greater precision without requiring us to abandon the broader concept of Entity.

Why the Distinction Matters

That precision becomes useful when we look at the other things a business may need to model.

An order is something of interest to the business. So is a product, a location, or a transaction. Each may be represented as an entity in a model.

But people and organizations are different in an important way: they can perform roles and participate in relationships while retaining their underlying identity.

The term Party tells us that this is the kind of entity we are talking about.

That shared meaning becomes especially valuable when data crosses business processes or systems. A Customer in one context and an Employee in another may still refer to the same Party.

A Technically Sound Model Can Still Fail

But precision in the model is only part of the challenge.

A model can be technically sound and still fail.

Enterprise data models depend on a shared understanding between the people creating the model and the people whose business the model represents.

If the business already uses the word entity in a particular way, simply telling people that their terminology is wrong can create an unnecessary barrier.

The model may be accurate, but if the people who need to use it feel that their language or expertise has been dismissed, they may never accept the model.

That does not mean the modeler should simply adopt every business term without examining what it means.

The modeler’s responsibility is to listen first, understand what the business means by its terminology, and then make the concepts in the model clear and unambiguous.

Sometimes that means retaining the business term. Sometimes it means introducing a modeling term such as Party and explaining why the distinction is useful.

The goal is not to win an argument about vocabulary.

The goal is to create a model that accurately represents the business and that the business can recognize as its own.

Moving from Identity to Roles

Party gives us that precision for people and organizations.

Once we have identified the Party, the next question is what that Party does.

And the answer is not always just one thing.

A person or organization may participate in the business in several different ways at the same time.

Next in This Series

One Party, Many Roles

Return to the Understanding Data Modeling Series Index

November 2, 2026
What Is a Party?

Consider two examples.

Maria is a person. She has a name, an identity, and information that describes who she is.

Northstar Services is an organization. It also has a name, an identity, and information that describes the organization.

Maria and Northstar Services are clearly different. One is a person and the other is an organization.

But from a data modeling perspective, they have something important in common.

The business may need to recognize each of them separately from the roles they perform.

Maria might be an employee, a customer, or a volunteer.

Northstar Services might be a supplier, a customer, or a business partner.

As we saw in the previous post, those roles can change without changing the underlying identity.

The Party Model needs a common concept for representing that identity.

That concept is Party.

A Party represents a person or organization whose identity we need to distinguish from the roles that person or organization performs.

Party gives us a common way to represent identity. It does not mean that people and organizations are identical. A person and an organization have different characteristics and may require different information.

What they share is the ability to participate in the business while retaining their own identity.

Maria does not become a different person because she is both an employee and a customer. Northstar Services does not become a different organization because it is both a supplier and a business partner.

The Party remains the same. What it does can change.

A useful question is:

“Who is the person or organization, apart from the role it is performing right now?”

That question points us toward the Party.

The word Party may sound unusual, especially when Entity is already a familiar term in data modeling. So why introduce another term?

Next in This Series

Why Not Just Call It Entity?

Return to the Understanding Data Modeling Series Index

November 2, 2026
Identity and Role Are Different Questions
The central idea behind the Party Model is the separation of identity from role.

Identity answers the question:

“Who is this person or organization?”

Role answers a different question:

“What part does this person or organization perform in a particular business context?”

Consider a person named Maria.

Maria may be:
- An employee
- A customer
- A volunteer
- A supplier contact
- A member of a professional organization
Those are not five different people. They are five roles performed by the same person.

Information such as Maria’s name and identifying details describes the party. Information such as her employee number, customer account, volunteer assignment, or supplier responsibilities describes a particular role or relationship.

This distinction matters because roles change.

Maria may leave her employment but remain a customer. She may stop volunteering and later become a contractor. Her roles can begin, end, overlap, or change while her underlying identity remains the same.

If each role is modeled as a separate person, the organization may create duplicate records and lose the ability to recognize that those records refer to the same real-world individual.

Separating Identity from Business Context

The Party Model separates these concepts:
- Party records the identity.
- Party Role records the capacity in which the party participates.
- Party Relationship connects one party to another within a defined context.
This allows the model to preserve one identity while supporting multiple roles over time.

The distinction also helps determine what information describes the underlying identity and what information describes a particular business context.

A person’s name describes the person. An employee number describes the person’s employment context. A customer account number describes a particular customer context.

A useful test is to ask:

“Would this information still describe the person or organization if this particular role ended?”

If the answer is no, the information probably belongs with the role or relationship rather than with the party’s identity.

Next in This Series

What Is a Party?

Return to the Understanding Data Modeling Series Index

For More Information

The Party Model and the patterns discussed in this series are strongly influenced by the work of Len Silverston.

For a deeper treatment of reusable data modeling patterns, including party roles, relationships, classifications, hierarchies, and contact mechanisms, see:

Len Silverston and Paul Agnew, The Data Model Resource Book, Volume 3: Universal Patterns for Data Modeling, Wiley.

Additional articles and historical material from The Data Administration Newsletter (TDAN) are available through DATAVERSITY.
November 2, 2026
Why Was the Party Model Needed?
When I began working with the Party Model in 2012, Len Silverston was the first authority I turned to.

Silverston did not necessarily invent every underlying concept. Similar modeling ideas existed before his work. His important contribution was bringing those ideas together, developing them into a practical enterprise pattern, and explaining the pattern so data modelers could apply it consistently.

What Problem Was He Trying to Solve?

Organizations commonly create separate records for:
- Customer
- Employee
- Supplier
- Contractor
- Partner
- Volunteer
That seems reasonable because those are the terms the business uses. However, the same person or organization can appear in several of these categories.

A person might be both an employee and a customer. A consultant might operate through a company that is both a supplier and a business partner.

If every role is modeled separately, the enterprise may create multiple records for the same real-world person or organization.

That leads to duplicate names, addresses, telephone numbers, email addresses, and identifiers.

It also makes it difficult to determine whether several records represent different parties or the same party performing different roles.

The Party Model Begins with a Different Question

Instead of asking, “Is this a customer, employee, or supplier?” it first asks:

“Who is this person or organization?”

Once identity is established, the model can record the roles that the party performs.

That separation between identity and role is the central idea behind the Party Model.

Next in This Series

Identity and Role Are Different Questions

Return to the Understanding Data Modeling Series Index
November 2, 2026
Define the Task and the Desired Outcome
One of the simplest ways to improve an AI response is to be clear about what you want the AI to do.

Consider the following prompt:

“Review this document.”

What does review mean?

Should the AI summarize the document? Identify errors? Evaluate risks? Recommend changes? Determine whether the document is ready for approval?

All of those are reasonable interpretations.

The AI may produce a useful response, but it may not produce the response you actually need.

Define the Task

Start by explaining the work you want performed.

For example:

“Review this project proposal and identify missing requirements, unclear assumptions, and unresolved decisions.”

Instead of asking for a general review, we have identified three specific areas to examine.

Define the Desired Outcome

Next, describe what the completed work should look like.

For example:

“Organize your findings into a table showing each issue, its potential business impact, and a recommended next action.”

Now the AI understands both the assignment and the expected result.

The task describes the work to perform. The desired outcome describes what a successful response should provide.

A Sample Prompt

Let’s combine those instructions into a prompt you can try with a document you are authorized to share using your organization’s approved AI tools.

Remember: text inside square brackets [ ] represents information you should replace with details specific to your situation.
<prompt> Review the following project proposal. Task: Identify missing requirements, unclear assumptions, unresolved decisions, and potential risks. Desired outcome: Organize your findings into a table containing: 1. Issue or observation 2. Why it matters 3. Recommended next action Separate findings supported by the document from questions that require additional information. Do not invent missing requirements or present assumptions as established facts. Conclude with the three most important items that should be resolved before the proposal moves forward. If the document does not provide enough information to evaluate an issue, identify what is missing rather than guessing. Document: [Insert approved document content here] </prompt>
Why Does This Matter?

AI can generate a polished answer even when it has misunderstood the assignment.

Clear instructions improve the likelihood of receiving a useful response, but they do not guarantee accuracy.

You must still review the results, verify important claims, and decide whether the recommendations make sense.

For business use, the distinction between known facts and inferred conclusions is especially important.

The Key Point

Before submitting a prompt, ask yourself two questions:

What work do I want the AI to perform?

What should the completed result look like?

When those questions are answered clearly, AI becomes easier to direct, evaluate, and use responsibly.

The goal is not simply to get an answer.

It is to get an answer that helps accomplish the intended business outcome.

Continue Exploring the Series

This article concludes our initial collection of nine Practical and Responsible AI posts.

Visit the Practical and Responsible AI series index to explore the other articles and additional topics as the series grows.

Return to the Practical and Responsible AI Series Index
November 2, 2026
Tell AI Who the Audience Is
In the last post, we used the same project information to create two different status updates. One was for an executive sponsor, and the other was for the project team.

The facts did not change, but the audience did.

Knowing who will use the information can help AI determine what needs explanation, what level of detail may be useful, which terminology is appropriate, and what information deserves emphasis.

But simply saying “this is for an executive” or “this is for a technical audience” may not provide enough information.

Consider two directors reviewing a data model. One may have deep modeling experience and already understand the model, its terminology, and its history. Another may have little modeling experience and need the underlying concepts explained before considering the business implications.

Both have the same job level. Both may be involved in the same decision. But an explanation appropriate for one could be unnecessarily simplified—or unnecessarily technical—for the other.

An audience is more than a job title. Their knowledge, responsibilities, authority, and concerns can all affect what makes a response useful.

When the audience matters, tell AI more than who they are. Give it enough information to understand what they already know, what they need from the response, and what they may need to do with it.

Sample Prompt

Here is a simple way to see why describing the audience matters. Start with a short piece of technical information and tell AI only the audience’s job level.

Source Material

The relationship between Customer and Account was changed from one-to-many to many-to-many. The revised model allows a customer to be associated with multiple accounts and an account to be associated with multiple customers. The change introduces an associative entity between Customer and Account.

First Prompt: Job Title Only
<prompt> Explain the following data model change for a director. Preserve the facts in the source material. Do not invent reasons for the change, business benefits, or implications that are not stated. Source material: [Paste the Source Material above here] </prompt>
Now Describe the Audience

Next, keep the source material exactly the same but provide more information about the audience.

Second Prompt: Knowledge and Responsibilities
<prompt> Using the source material below, explain the change for a director with extensive data-modeling experience. The director is already familiar with this model and understands cardinality, many-to-many relationships, and associative entities. The director is reviewing the proposed change and needs to understand what changed in the model. Do not explain established modeling concepts unless necessary to explain the change. Preserve the facts in the source material. Do not invent reasons for the change, business benefits, or implications that are not stated. If the earlier explanation is available, briefly identify what you changed because you knew more about the audience. Source material: [Paste the same Source Material here] </prompt>
When trying this example, use the same source material for both prompts. That allows you to compare how additional audience information changes the explanation without changing the underlying facts.

Why This Works

Both prompts identify the audience as a director. The second prompt, however, tells AI something more useful: what the director already knows and what the director needs from the response.

Without that information, AI has to make assumptions about the audience. It may decide that a director needs a high-level explanation and spend much of the response defining concepts such as cardinality or associative entities.

That explanation might be useful for one director and unnecessary for another.

Describing the audience gives AI a better basis for deciding what to explain, what terminology it can use, how much detail may be appropriate, and what information deserves emphasis.

Audience context can include more than technical knowledge. Depending on the task, it may help to tell AI what the audience is responsible for, what decisions they can make, what concerns they have, and what they need to do with the information.

The goal is not to tell AI everything you know about the audience. It is to provide the audience information that matters for the task.

Before You Use the Results

Describing the audience can change how AI explains information. It should not change the underlying facts.

Compare the response with the original source material. Check that important facts, terminology, relationships, qualifications, and other details remain accurate.

Also watch for statements that sound reasonable but were not supported by the source.

In our example, the source says that the relationship changed from one-to-many to many-to-many and that an associative entity was introduced.

It does not explain why the change was made or what business benefits it is expected to provide.

If AI supplies a reason or benefit, that information should not be treated as fact simply because it sounds plausible.

Audience information can help AI produce a response that is better suited to the person who will use it, but it does not make unsupported information more reliable.

You remain responsible for making sure the final explanation accurately represents the source and is appropriate for the intended audience.

Next in This Series

Define the Task and the Desired Outcome

We’ll look at how clearly defining the task and desired outcome can help AI understand what you actually want it to produce.

Return to the Practical and Responsible AI Series Index
November 2, 2026
Why Context Changes the Answer
Two people can ask AI the same question and need very different answers.

Imagine asking AI, “What should I include in a project status update?” The answer you need may depend on whether the update is for your project team, an executive sponsor, or a customer.

An executive may need the overall status, significant risks, and decisions requiring attention, while the project team may need activities, responsibilities, dependencies, and next steps.

The underlying project information may be the same, but the context changes what is useful to the reader.

AI does not automatically know the context of your situation. You need to provide the information it needs to interpret your request.

In the first six posts in this series, the sample prompts included details about the task, audience, information to preserve, and things AI should not assume. Those details were not just extra instructions. They gave AI context for interpreting the request.

Context helps AI understand not only what you are asking, but what an appropriate answer needs to account for.

Sample Prompt

Here is a simple way to see the effect of context. Start with one set of project notes, then ask AI to use the same information for two different situations.

Source Material

The customer portal upgrade is scheduled for October 15. User acceptance testing began September 14 and is expected to finish September 25. Testing has identified three issues; two have been resolved. The remaining issue affects password-reset emails and is being investigated by the development team. Training materials are in draft and are scheduled for review September 28. No change to the October 15 target date has been approved.

First Prompt: Executive Sponsor
<prompt> Using the project notes below, prepare a brief status update for the executive sponsor. The purpose is to communicate overall progress, significant risks, and anything that may require attention or a decision. Keep the update concise. Preserve the facts, dates, risks, decisions, and qualifications in the source material. Do not invent missing information or make unsupported conclusions or recommendations. If important information is missing, identify it rather than guessing. Project notes: [Paste the Source Material above here] </prompt>
Now Change the Context

Next, keep the source material exactly the same but change the audience and purpose.

Second Prompt: Project Team
<prompt> Using exactly the same project notes, prepare a status update for the project team. The purpose is to help the team understand current activities, unresolved issues, upcoming work, and dependencies. Preserve the same facts, dates, risks, decisions, and qualifications. Do not add information that is not in the project notes or make unsupported conclusions or recommendations. After drafting the second version, briefly identify what you changed from the executive version because the audience and purpose changed. Project notes: [Paste the same Source Material here] </prompt>
When you try this with your own material, replace the sample project notes with your source information. Keep the source material the same for both prompts so you can see what changes when you change the context.

Why This Works

The source material did not change. The context did.

In the first prompt, AI was told that the update was for an executive sponsor who needed overall progress, significant risks, and anything requiring attention or a decision.

In the second, the audience changed to the project team, and the purpose shifted toward current activities, unresolved issues, upcoming work, and dependencies.

Those differences give AI information about what to emphasize, how much detail may be useful, and how to organize the response.

The underlying facts should remain the same, but the way those facts are presented can change to fit the situation.

Context can include more than audience and purpose. Background information, terminology, current circumstances, and other details can all affect how AI interprets a request.

Providing context does not guarantee that the response will be correct. It gives AI a better basis for producing a response that fits what you actually need.

Before You Use the Results

Changing the context can change what AI emphasizes, how it organizes the information, and the level of detail it provides. It should not change the underlying facts.

Compare each response with the original source material. Check that dates, decisions, risks, qualifications, and other important details remain accurate.

Pay particular attention to statements that sound reasonable but go beyond what the source actually says.

In our example, the notes say that no change to the October 15 target date has been approved.

That is not the same as saying the unresolved issue will have no effect on the schedule.

If AI makes that leap, the response should be corrected.

AI can help shape information for a particular situation, but you remain responsible for making sure the result accurately represents the source.

Next in This Series

Tell AI Who the Audience Is

We’ll look more closely at how telling AI who the audience is can change the response.

Return to the Practical and Responsible AI Series Index
November 2, 2026