Chapter 27
Not everyone needs to see everything
It had been three months.
The notebooks were gone.
The Excel sheets were archived.
The sticky notes had disappeared from the counter.
Gary leaned back in his chair and looked at the screen.
Albums.
Artists.
Customers.
Orders.
Notes.
Purchase history.
VIP status.
Internal comments.
Everything lived inside one system now.
And for the first time, it felt… stable.
But then...
A new discomfort
Lisa was helping a customer at the counter.
She searched for the customer’s name.
The profile opened.
Purchase history.
Contact details.
Preferences.
Internal notes.
Gary froze.
Internal notes.
There it was.
“Late payments twice.”
“Call before ordering rare imports.”
“Possible reseller.”
Lisa scrolled casually.
Gary felt something tighten in his chest.
After the customer left, he turned to Sam.
“Everyone can see everything,” he said.
Sam nodded slowly.
“Yes.”
“And I don’t think that’s right.”
The difference between data and access
Sam didn’t touch the keyboard.
“Your model is correct,” he said.
“The structure is sound.”
Gary nodded.
“That’s not the problem.”
“No,” Sam agreed.
“The problem is visibility.”
Gary frowned.
“I thought once we modeled everything correctly, we were done.”
Sam shook his head.
“Modeling defines what exists.
Permissions define who is allowed to see it.”
Not all information is equal
Albums and artists were public inside the store.
There was no harm in everyone seeing:
- Artist biography
- Release year
- Genre
- Stock level
Customer information was different.
Some information was operational.
Some was sensitive to the business.
Some was personal to the customer.
Gary leaned forward.
“So we moved everything into one system…
and now I need to split it apart again?”
Sam paused.
“Not automatically,” he said.
“But sometimes.”
He continued carefully.
“If a single object contains information that requires different visibility,
it can become difficult to govern correctly.”
Gary listened.
“Read rules apply to classifications attached to rows.
If one row mixes information that should be governed differently,
the structure may need to evolve.”
Gary looked thoughtful.
“So some objects might need a base part
and a more restricted related part.”
“Yes,” Sam said.
“Not because the system is wrong.
But because visibility follows structure.”
One model, explicit visibility
Sam turned the laptop slightly.
“Right now,” he said, “everyone can see the same data.”
Gary frowned.
“Because we didn’t restrict it?”
“It’s because your system is using an optimistic read policy,” Sam replied.
“That means data is visible unless a rule denies access.”
Gary nodded slowly.
“So visibility always starts from a baseline.”
“Yes.”
“You choose the posture:
- Optimistic — readable unless denied
- Pessimistic — hidden unless allowed”
“And we’re optimistic.”
“Yes. Which means without read rules, everything is visible.”
Gary looked back at the internal notes.
“So the structure stays the same.”
“Yes.”
“But visibility is defined explicitly.”
Sam nodded.
“The model defines what exists.
The read policy defines the default.
Read rules refine it.”
Gary leaned back.
“When would I use pessimistic instead?”
Sam didn’t answer immediately.
“Optimistic works well when most information should be visible internally,
and only specific parts need restriction.”
He continued.
“Pessimistic is used when visibility itself is sensitive —
when access must be explicitly granted before anything can be read.”
Gary considered that.
“So optimistic is open by default.
Pessimistic is closed by default.”
“Yes.”
“It’s not about which one is better,” Sam said.
“It’s about your trust posture.”
Gary nodded slowly.
“For a record store, optimistic makes sense.”
Sam smiled.
“For a law firm or a medical clinic, maybe not.”
Gary looked back at the screen.
“So the policy defines the default trust level.”
“Yes,” Sam said.
“And the rules define the exceptions.”
From roles to read rules
Gary already had roles:
- Owner
- Staff
That had been enough when rules were about validity.
But now the question wasn’t:
Is this album allowed to exist?
It was:
Who is allowed to read which rows?
Sam leaned back.
“Read rules are attached to classifications.
Classifications belong to rows.”
Gary nodded slowly.
“So I can’t just hide one random piece.”
“No,” Sam said.
“The structure must support the visibility you want.”
He pointed at the screen.
“If all information in a row shares the same governance, it stays simple.”
“And if it doesn’t?”
“Then the structure matures.”
Gary exhaled.
“So this isn’t about hiding data.”
“No.”
“It’s about designing the structure so trust can be enforced.”
Continue reading
Gary understood the principle.
Different information required different governance.
Some objects might need refinement.
Visibility followed structure.
But understanding the idea was one thing.
Implementing it was another.
Which classifications should remain open to Staff?
Which should be restricted to Owner?
Should the system remain optimistic — or shift to a stricter posture?
Gary turned to Sam.
“Alright,” he said.
“Let’s define exactly who can read what.”
In the next chapter, Gary and Sam sit down to define and implement their first read rules.