Core Object Map

Start with the Promise, Not the Tables

A core object map is a product model before it is a database design. It names what the product believes exists, who owns it, how it changes, and which history must survive the happy path.

Draw one before the first durable schema, and redraw it when discovery changes the important nouns or boundaries. It should be small enough to inspect on one page. The objective is not to capture the whole domain. It is to find the smallest connected world that can deliver today’s promise, protect it, explain a failure, and reveal whether value occurred.

Begin with one sentence:

For [actor], the product has delivered value when [observable outcome].

“A user uploads a file” describes an input. “A user has a dashboard” describes an interface. Neither says what became better in the customer’s world.

Suppose a product helps an account manager turn an advertising export into a reviewed weekly digest and send it to a client. Its promise is:

An account manager sends a trustworthy explanation of weekly ad-account changes to a client without spending an hour assembling it.

Now add a support question the model must answer after something goes wrong:

Who changed the Acme digest yesterday, what did the client receive, and why does the product say it was sent?

The promise pulls the map forward. The support question forces it to preserve enough truth to travel backward.

Find the Objects That Carry the Work

List the durable nouns required by the promise. For each candidate, ask whether it has an identity or lifecycle the product must remember. A screen, a form field, and a dashboard panel are usually views of an object rather than objects themselves. An event records that something happened; it should not replace the thing to which it happened.

Use one card for each object:

Object:
Meaning in the customer's work:
Why the product must remember it:
Owned by:
Created by:
Identity that remains stable:
States that change permitted behavior:
History that must survive an edit:
Deletion or retention question:
Open assumption:

The agency product needs six objects for its first promise:

• agency_account owns customer work, membership, and billing.
• account_user identifies the person acting for an agency.
• client identifies the business for which the agency prepares work; the client does not yet need a login.
• source_export preserves what entered the system and whether it could be used.
• change_digest carries the product’s value and the reviewed version of the explanation.
• delivery records an attempt to send a particular digest version to a recipient through a channel.

These distinctions answer questions that a single users table and mutable report cannot. The person who created work is not necessarily its owner. A digest being approved does not prove that a provider delivered it. Editing today’s digest must not rewrite what a client received yesterday.

Connect Objects with Verbs

Relationships should say what is true in the product, not merely what can be joined in a database. Draw each connection as a sentence, then add cardinality only when the current workflow requires it.

agency_account owns client
account_user is a member of agency_account
client supplies source_export
change_digest is derived from source_export
account_user reviews a version of change_digest
delivery sends an approved version of change_digest to a recipient

Read every line in both directions. If an account owns a client, can a client move between accounts? If a digest is derived from an export, can several digests use the same export? Discovery may not have answered yet. Mark the uncertainty instead of allowing an accidental schema constraint to answer it.

For the relationships most likely to become expensive, keep a short record:

Relationship:
Customer evidence:
Rule enforced now:
Uncertain variation:
Consequence if the rule is wrong:
Cheapest way to learn:

Give Important Work an Honest Lifecycle

Add states only when a transition changes what someone may do, what the product promises, or how a failure is repaired. “Complete” is usually too vague.

The agency map can trace three separate lifecycles:

source_export: received -> parsed | rejected
change_digest: draft -> ready_for_review -> approved -> archived
delivery: queued -> accepted -> delivered | failed | unknown

The exact delivery states depend on facts the provider can report. accepted must not silently acquire the meaning of delivered. For every consequential transition, note who or what may cause it, what becomes allowed, what history is retained, and what happens when the transition fails halfway.

Do not force every object into a state machine. An object whose meaningful facts do not change may need no named lifecycle.

Draw the Trust Boundary Through the Map

Ownership becomes real when it controls access. Finish these sentences for each action that can expose data, spend money, release work, or cause an irreversible change:

[actor] may [action] on [object] because [relationship or role].
The rule is enforced at [boundary shared by UI, API, jobs, files, and tools].
The action leaves [history or evidence].

For the pilot, an account user may reach only clients, exports, digests, and deliveries owned by that user’s agency account. All members may draft and review; only the account owner may invite members or change billing. Removing a user does not erase agency-owned work. The founder’s support access uses a separate, constrained path and leaves a trace.

Test the map with two accounts. Attempt the same read, update, file download, background operation, and administrative action from the wrong account. A neat ownership arrow that is not enforced along every access path is decoration.

Attach Learning to Things the Product Understands

The next artifact will define events. Here, decide which objects give those events meaning. Acquisition may belong to an account; activation may require a parsed source export and an approved digest; delivered value may attach to a particular delivery; repeated value should remain traceable to the same account and client.

Record the evidence anchors without designing a universal analytics taxonomy:

Product question:
Object and stable identifier:
Behavior or transition that supplies evidence:
Properties required to interpret it:
Sensitive data deliberately excluded:
Operational failure that could make the evidence false:

This step often exposes a missing object. If the founder wants to measure “reports sent” but cannot distinguish a digest, its approved version, a delivery attempt, and a provider result, the metric will inherit the model’s ambiguity.

Put the Imagined Platform Outside the Boundary

A useful map includes an exclusion list. The agency founder can imagine workspaces, team hierarchies, custom roles, comments, reusable templates, client portals, labels, and generalized integrations. None belongs inside merely because it is plausible.

For each excluded object, name the evidence that would earn it:

Excluded object or distinction:
Why it is unnecessary now:
Evidence that would bring it inside:
Cost or risk of adding it too early:

Account isolation, confidential source files, money, and externally released work are different. They are already inside the product’s present trust boundary, so “we are still early” does not make them optional.

Run Two Traces Before Designing the Schema

First, trace one instance forward from actor to delivered value:

agency account -> client -> source export -> digest version -> approval -> delivery

At each step, identify the owner, permitted actor, state transition, failure path, and evidence left behind.

Then start with the support question and trace backward from the recipient to the delivery, exact digest version, source export, acting user, and owning account. If the chain breaks, the map is missing a fact. If the chain crosses an ownership boundary without an explicit permission, it is unsafe. If the page has become a wall, remove objects that carry neither the promise, the trust boundary, support, nor current learning.

Finish with one change exercise. Suppose discovery shows that each client has several advertising accounts with independent exports and reporting schedules. Where does ad_account enter the map? Which existing identifiers and histories must remain stable? What migration can add and backfill the relationship without silently reinterpreting old records?

The map is ready to guide the first schema when it can answer five questions without pretending to describe the future business:

• Who owns this work?
• Who may see or change it, and why?
• Where is it in the value-producing workflow?
• What happened when the workflow failed?
• What evidence shows that the customer received value?

Preserve the map beside the product decision it supports. Revise it when customer evidence changes the world the product must represent—not whenever a new interface adds another noun.