Ephraim Feig told enterprise teams to “look for situations where you can have blockchain in collaborating communities.”
He contrasted those communities with a system designed for strangers who assume they cannot trust one another. Many enterprises already know their participants. Their harder problem may be deciding which participant can examine a pending record, what that person can confirm, and who is responsible for the final decision.
Ephraim's argument gives a blockchain proposal three gates to pass before the technology name carries any weight.
Gate one: the source has to be examined
Ephraim Feig warned, “The fraud happens before the data gets into the record.” A false charge, incorrect treatment, or misleading event can be preserved perfectly after someone enters it. Durability does not make the original statement true.
He later made the same point another way, saying “you can have consensus on garbage data.” Several copies can agree because every participant received the same bad input.
The first design task is therefore outside the ledger. Name the source of each important fact and the evidence available to check it before the fact becomes final.
Gate two: peers need something real to validate
Ephraim Feig used a healthcare example to describe a pending record reviewed by peers. An automated agent might compare the proposed entry with a patient's history and flag an omission or disagreement. A doctor would still decide whether the record should be accepted or changed.
The example was conceptual, not a reported production system. Its value is the role definition. A peer should contribute a review that the source participant cannot provide alone, and a responsible person should own the resolution.
This is closer to the Git model Ephraim discussed. Contributors propose changes, other participants test or discuss them, and trusted maintainers decide what enters the shared record. Open visibility does not mean every person receives authority to approve a change.
Gate three: the application must choose its own rules
When Ephraim Feig reached his enterprise framework, he did not offer one universal architecture. He asked teams to define the users, input data, peers, validation, consensus, mutability, and incentives for the actual business process.
A proposal can make those choices visible in a short operating statement:
- These users create or read the record.
- This source supplies each material input.
- These peers can verify these specific parts.
- This role resolves disagreement and finalizes the entry.
- This business reason justifies replication, consensus, or a tamper-evident chain.
If the team cannot complete the third sentence, adding more peers may create copies without adding validation. If the fifth sentence is weak, an existing database with hashes, replication, or notarization may meet the need with less change.
Immutability and incentives are choices too
Ephraim Feig cautioned that an enterprise may need to correct or remove information. A permanent record can conflict with the business or legal need to change it. He also noted that enterprise peers may already be motivated by salary, bonuses, reputation, or shared utility rather than a mining reward.
Those choices belong in the design before a vendor presents the architecture as inevitable. His closing guidance was plain: “You have to design it depending on your business and your application.” A collaborative community is useful only when its members can contribute a meaningful check and the system preserves a human decision about what happens next.
