diff --git a/predicates/1-predicate-analysis.md b/predicates/1-predicate-analysis.md
index 6289540..c185bca 100644
--- a/predicates/1-predicate-analysis.md
+++ b/predicates/1-predicate-analysis.md
@@ -1,176 +1,175 @@
 # Canonical Predicate Catalog Analysis
 
-## Top 100 Predicates
+## Canonical Launch Predicate Catalog
 
-### Identity and Classification (1-8)
+The launch catalog currently contains 97 predicates after removing overloaded/de-duplicated identity predicates (`is`, `alias of`, `instance of`, and `subclass of`). Use `has type`, `same as`, `has tag`, and `has category` for the remaining identity/classification cases.
+
+### Identity and Classification (1-4)
 
 | # | Predicate | Intent | Typical Triple Pattern |
 |---|---|---|---|
-| 1 | `is` | Identity or type assertion | `(Ethereum, is, blockchain)` |
-| 2 | `has type` | Type classification | `(Uniswap, has type, DEX)` |
-| 3 | `same as` | Cross-representation identity | `(ETH, same as, Ether)` |
-| 4 | `alias of` | Alternative name | `(BTC, alias of, Bitcoin)` |
-| 5 | `instance of` | Class membership | `(USDC, instance of, stablecoin)` |
-| 6 | `subclass of` | Taxonomy hierarchy | `(DEX, subclass of, exchange)` |
-| 7 | `has tag` | Free-form tagging | `(Aave, has tag, lending)` |
-| 8 | `has category` | Categorical grouping | `(Chainlink, has category, oracle)` |
+| 1 | `has type` | Formal taxonomy or defined-term classification | `(Uniswap, has type, Decentralized Exchange)` |
+| 2 | `same as` | Cross-representation identity and duplicate collapsing | `(ETH, same as, Ether)` |
+| 3 | `has tag` | Free-form tagging | `(Aave, has tag, lending)` |
+| 4 | `has category` | Product-level browsable grouping | `(Uniswap, has category, DeFi)` |
 
-### Social and Reputation (9-18)
+### Social and Reputation (5-14)
 
 | # | Predicate | Intent | Typical Triple Pattern |
 |---|---|---|---|
-| 9 | `follows` | Unidirectional subscription | `(Alice, follows, Bob)` |
-| 10 | `likes` | Lightweight positive signal | `(Alice, likes, Ethereum)` |
-| 11 | `endorses` | Strong public support | `(Vitalik, endorses, EIP-4844)` |
-| 12 | `trusts` | Positive trust assertion | `(Alice, trusts, Auditor X)` |
-| 13 | `distrusts` | Negative trust assertion | `(Alice, distrusts, Scam Project)` |
-| 14 | `reviewed` | Review authorship | `(Alice, reviewed, Uniswap v4)` |
-| 15 | `recommended` | Active recommendation | `(Alice, recommended, Hardhat)` |
-| 16 | `reported` | Flagging for violation | `(Alice, reported, Phishing Site)` |
-| 17 | `blocked` | Exclusion from view | `(Alice, blocked, Spam Account)` |
-| 18 | `vouches for` | Personal credibility stake | `(Alice, vouches for, Bob)` |
-
-### Curation and Containment (19-25)
+| 5 | `follow` | Unidirectional subscription | `(I, follow, Vitalik)` |
+| 6 | `like` | Lightweight positive signal | `(I, like, Ethereum)` |
+| 7 | `endorse` | Strong public support | `(I, endorse, EIP-4844)` |
+| 8 | `trust` | Positive trust assertion | `(I, trust, Auditor X)` |
+| 9 | `distrust` | Negative trust assertion | `(I, distrust, Scam Project)` |
+| 10 | `reviewed` | Review authorship | `(I, reviewed, Uniswap v4)` |
+| 11 | `recommend` | Active recommendation | `(I, recommend, Hardhat)` |
+| 12 | `reported` | Flagging for violation | `(I, reported, Phishing Site)` |
+| 13 | `blocked` | Exclusion from view | `(I, blocked, Spam Account)` |
+| 14 | `vouch for` | Personal credibility stake | `(I, vouch for, Bob)` |
+
+### Curation and Containment (15-22)
 
 | # | Predicate | Intent | Typical Triple Pattern |
 |---|---|---|---|
-| 19 | `contains` | Collection membership | `(L1 Watchlist, contains, Ethereum)` |
-| 20 | `curated by` | Collection ownership | `(DeFi Blue Chips, curated by, Alice)` |
-| 21 | `pinned in` | Highlighted in collection | `(Ethereum, pinned in, L1 Watchlist)` |
-| 22 | `featured in` | Editorially promoted | `(Uniswap, featured in, Top DEXs)` |
-| 23 | `ranked above` | Explicit ordering | `(Ethereum, ranked above, Solana)` |
-| 24 | `depends on` | Functional dependency | `(Arbitrum, depends on, Ethereum)` |
-| 25 | `alternative to` | Substitutability | `(Solana, alternative to, Ethereum)` |
+| 15 | `contain` | Collection membership | `(L1 Watchlist, contain, Ethereum)` |
+| 16 | `listed in` | Reverse collection membership | `(Ethereum, listed in, L1 Watchlist)` |
+| 17 | `curated by` | Collection ownership | `(DeFi Blue Chips, curated by, Alice)` |
+| 18 | `pinned in` | Highlighted in collection | `(Ethereum, pinned in, L1 Watchlist)` |
+| 19 | `featured in` | Editorially promoted | `(Uniswap, featured in, Top DEXs)` |
+| 20 | `ranked above` | Explicit ordering | `(Ethereum, ranked above, Solana)` |
+| 21 | `depend on` | Functional dependency | `(Arbitrum, depend on, Ethereum)` |
+| 22 | `alternative to` | Substitutability | `(Solana, alternative to, Ethereum)` |
 
-### Authorship and Contribution (26-31)
+### Authorship and Contribution (23-28)
 
 | # | Predicate | Intent | Typical Triple Pattern |
 |---|---|---|---|
-| 26 | `created by` | Origin attribution | `(Ethereum, created by, Vitalik Buterin)` |
-| 27 | `authored by` | Written content attribution | `(Whitepaper, authored by, Satoshi)` |
-| 28 | `contributed to` | Contribution record | `(Alice, contributed to, OpenZeppelin)` |
-| 29 | `forked from` | Divergent copy | `(Sushiswap, forked from, Uniswap)` |
-| 30 | `derived from` | Adaptation or build-upon | `(Optimism, derived from, Ethereum)` |
-| 31 | `inspired by` | Creative influence | `(Solana, inspired by, PBFT)` |
+| 23 | `created by` | Origin attribution | `(Ethereum, created by, Vitalik Buterin)` |
+| 24 | `authored by` | Written content attribution | `(Whitepaper, authored by, Satoshi)` |
+| 25 | `contributed to` | Contribution record | `(I, contributed to, OpenZeppelin)` |
+| 26 | `forked from` | Divergent copy | `(Sushiswap, forked from, Uniswap)` |
+| 27 | `derived from` | Adaptation or build-upon | `(Optimism, derived from, Ethereum)` |
+| 28 | `inspired by` | Creative influence | `(Solana, inspired by, PBFT)` |
 
-### Metadata and Linking (32-39)
+### Metadata and Linking (29-36)
 
 | # | Predicate | Intent | Typical Triple Pattern |
 |---|---|---|---|
-| 32 | `linked account` | Platform identity linkage | `(Alice, linked account, x.com/alice)` |
-| 33 | `url` | Canonical web address | `(Ethereum, url, ethereum.org)` |
-| 34 | `imgUrl` | Image reference (legacy) | `(Ethereum, imgUrl, eth-logo.png)` |
-| 35 | `has description` | Textual description | `(Ethereum, has description, "A decentralized...")` |
-| 36 | `has source` | Authoritative reference | `(EIP-4844, has source, eips.ethereum.org/...)` |
-| 37 | `published at` | Publication venue | `(Whitepaper, published at, bitcoin.org)` |
-| 38 | `located in` | Geographic or logical location | `(Devcon, located in, Bangkok)` |
-| 39 | `available on` | Platform availability | `(USDC, available on, Ethereum)` |
+| 29 | `linked account` | Platform identity linkage | `(Alice, linked account, x.com/alice)` |
+| 30 | `url` | Canonical web address | `(Ethereum, url, ethereum.org)` |
+| 31 | `imgUrl` | Image reference (legacy) | `(Ethereum, imgUrl, eth-logo.png)` |
+| 32 | `has description` | Textual description | `(Ethereum, has description, "A decentralized...")` |
+| 33 | `has source` | Authoritative reference | `(EIP-4844, has source, eips.ethereum.org/...)` |
+| 34 | `published at` | Publication venue | `(Whitepaper, published at, bitcoin.org)` |
+| 35 | `located in` | Geographic or logical location | `(Devcon, located in, Bangkok)` |
+| 36 | `available on` | Platform availability | `(USDC, available on, Ethereum)` |
 
-### Affiliation and Membership (40-45)
+### Affiliation and Membership (37-42)
 
 | # | Predicate | Intent | Typical Triple Pattern |
 |---|---|---|---|
-| 40 | `member of` | Organization membership | `(Alice, member of, Ethereum Foundation)` |
-| 41 | `employed by` | Employment relationship | `(Alice, employed by, Uniswap Labs)` |
-| 42 | `founded` | Founder attribution | `(Vitalik, founded, Ethereum)` |
-| 43 | `affiliated with` | General association | `(Protocol X, affiliated with, a16z)` |
-| 44 | `partner of` | Formal partnership | `(Chainlink, partner of, SWIFT)` |
-| 45 | `invested in` | Financial investment | `(a16z, invested in, Uniswap)` |
+| 37 | `member of` | Organization membership | `(I, member of, Ethereum Foundation)` |
+| 38 | `employed by` | Employment relationship | `(I, employed by, Uniswap Labs)` |
+| 39 | `founded` | Founder attribution | `(Vitalik, founded, Ethereum)` |
+| 40 | `affiliated with` | General association | `(Protocol X, affiliated with, a16z)` |
+| 41 | `partner of` | Formal partnership | `(Chainlink, partner of, SWIFT)` |
+| 42 | `invested in` | Financial investment | `(a16z, invested in, Uniswap)` |
 
-### Domain-Specific Knowledge (46-50)
+### Domain-Specific Knowledge (43-47)
 
 | # | Predicate | Intent | Typical Triple Pattern |
 |---|---|---|---|
-| 46 | `uses` | Technology utilization | `(Aave, uses, Chainlink)` |
-| 47 | `compatible with` | Interoperability | `(MetaMask, compatible with, Ethereum)` |
-| 48 | `governed by` | Governance authority | `(Uniswap, governed by, UNI holders)` |
-| 49 | `priced in` | Denomination currency | `(NFT Collection, priced in, ETH)` |
-| 50 | `implements` | Standard implementation | `(USDC, implements, ERC-20)` |
+| 43 | `use` | Technology utilization | `(Aave, use, Chainlink)` |
+| 44 | `compatible with` | Interoperability | `(MetaMask, compatible with, Ethereum)` |
+| 45 | `governed by` | Governance authority | `(Uniswap, governed by, UNI holders)` |
+| 46 | `priced in` | Denomination currency | `(NFT Collection, priced in, ETH)` |
+| 47 | `implement` | Standard implementation | `(USDC, implement, ERC-20)` |
 
-### Sentiment and Opinion (51-58)
+### Sentiment and Opinion (48-55)
 
 | # | Predicate | Intent | Typical Triple Pattern |
 |---|---|---|---|
-| 51 | `agrees with` | Alignment of position | `(Alice, agrees with, EIP-4844)` |
-| 52 | `disagrees with` | Opposition of position | `(Alice, disagrees with, PoW Revival)` |
-| 53 | `supports` | Active backing of a cause or proposal | `(Coinbase, supports, MiCA regulation)` |
-| 54 | `opposes` | Active resistance to a cause or proposal | `(Mining Pool X, opposes, PoS transition)` |
-| 55 | `skeptical of` | Cautious doubt without full rejection | `(Alice, skeptical of, Restaking)` |
-| 56 | `bullish on` | Positive conviction about future value | `(Alice, bullish on, Ethereum)` |
-| 57 | `bearish on` | Negative conviction about future value | `(Alice, bearish on, Memecoins)` |
-| 58 | `neutral on` | Explicit non-position | `(Alice, neutral on, L2 wars)` |
+| 48 | `agree with` | Alignment of position | `(I, agree with, EIP-4844)` |
+| 49 | `disagree with` | Opposition of position | `(I, disagree with, PoW Revival)` |
+| 50 | `support` | Active backing of a cause or proposal | `(I, support, MiCA regulation)` |
+| 51 | `oppose` | Active resistance to a cause or proposal | `(I, oppose, PoS transition)` |
+| 52 | `skeptical of` | Cautious doubt without full rejection | `(I, skeptical of, Restaking)` |
+| 53 | `bullish on` | Positive conviction about future value | `(I, bullish on, Ethereum)` |
+| 54 | `bearish on` | Negative conviction about future value | `(I, bearish on, Memecoins)` |
+| 55 | `neutral on` | Explicit non-position | `(I, neutral on, L2 wars)` |
 
-### Comparison and Ranking (59-66)
+### Comparison and Ranking (56-63)
 
 | # | Predicate | Intent | Typical Triple Pattern |
 |---|---|---|---|
-| 59 | `better than` | Subjective superiority claim | `(Rust, better than, Solidity)` |
-| 60 | `worse than` | Subjective inferiority claim | `(PoW, worse than, PoS)` |
-| 61 | `equivalent to` | Functional parity | `(USDC, equivalent to, USDT)` |
-| 62 | `competes with` | Direct market competition | `(Uniswap, competes with, Curve)` |
-| 63 | `outperforms` | Measurable superiority | `(Solana, outperforms, Ethereum)` |
-| 64 | `supersedes` | Replacement of a predecessor | `(Uniswap v4, supersedes, Uniswap v3)` |
-| 65 | `predecessor of` | Versioning lineage | `(Uniswap v2, predecessor of, Uniswap v3)` |
-| 66 | `successor of` | Forward version link | `(Uniswap v3, successor of, Uniswap v2)` |
+| 56 | `better than` | Subjective superiority claim | `(Rust, better than, Solidity)` |
+| 57 | `worse than` | Subjective inferiority claim | `(PoW, worse than, PoS)` |
+| 58 | `equivalent to` | Functional parity | `(USDC, equivalent to, USDT)` |
+| 59 | `compete with` | Direct market competition | `(Uniswap, compete with, Curve)` |
+| 60 | `outperform` | Measurable superiority | `(Solana, outperform, Ethereum)` |
+| 61 | `supersede` | Replacement of a predecessor | `(Uniswap v4, supersede, Uniswap v3)` |
+| 62 | `predecessor of` | Versioning lineage | `(Uniswap v2, predecessor of, Uniswap v3)` |
+| 63 | `successor of` | Forward version link | `(Uniswap v3, successor of, Uniswap v2)` |
 
-### Knowledge and Expertise (67-74)
+### Knowledge and Expertise (64-71)
 
 | # | Predicate | Intent | Typical Triple Pattern |
 |---|---|---|---|
-| 67 | `expert in` | Domain expertise claim | `(Alice, expert in, ZK proofs)` |
-| 68 | `learned from` | Knowledge attribution | `(Alice, learned from, Bob)` |
-| 69 | `teaches` | Knowledge dissemination | `(Alice, teaches, Solidity)` |
-| 70 | `studied` | Learning engagement | `(Alice, studied, cryptography)` |
-| 71 | `certified by` | Credential attestation | `(Alice, certified by, Ethereum Foundation)` |
-| 72 | `mentor of` | Mentorship relationship | `(Bob, mentor of, Alice)` |
-| 73 | `student of` | Apprenticeship relationship | `(Alice, student of, Bob)` |
-| 74 | `speaks` | Language or communication capability | `(Alice, speaks, Rust)` |
+| 64 | `expert in` | Domain expertise claim | `(I, expert in, ZK proofs)` |
+| 65 | `learned from` | Knowledge attribution | `(I, learned from, Bob)` |
+| 66 | `teach` | Knowledge dissemination | `(I, teach, Solidity)` |
+| 67 | `studied` | Learning engagement | `(I, studied, cryptography)` |
+| 68 | `certified by` | Credential attestation | `(I, certified by, Ethereum Foundation)` |
+| 69 | `mentor of` | Mentorship relationship | `(I, mentor of, Alice)` |
+| 70 | `student of` | Apprenticeship relationship | `(I, student of, Bob)` |
+| 71 | `speak` | Language or communication capability | `(I, speak, Rust)` |
 
-### Provenance and Evidence (75-82)
+### Provenance and Evidence (72-79)
 
 | # | Predicate | Intent | Typical Triple Pattern |
 |---|---|---|---|
-| 75 | `verified by` | Third-party verification | `(Smart Contract, verified by, CertiK)` |
-| 76 | `audited by` | Security or financial audit | `(Aave v3, audited by, Trail of Bits)` |
-| 77 | `attested by` | Witness or attestation | `(Credential, attested by, Issuer)` |
-| 78 | `cited by` | Academic or reference citation | `(Bitcoin Whitepaper, cited by, Ethereum Whitepaper)` |
-| 79 | `references` | Forward citation or mention | `(Ethereum Whitepaper, references, Bitcoin Whitepaper)` |
-| 80 | `evidenced by` | Supporting proof or data | `(Claim, evidenced by, On-chain Proof)` |
-| 81 | `disputed by` | Challenge to a claim | `(Claim, disputed by, Counter-evidence)` |
-| 82 | `confirmed by` | Corroboration of a claim | `(Claim, confirmed by, Independent Source)` |
+| 72 | `verified by` | Third-party verification | `(Smart Contract, verified by, CertiK)` |
+| 73 | `audited by` | Security or financial audit | `(Aave v3, audited by, Trail of Bits)` |
+| 74 | `attested by` | Witness or attestation | `(Credential, attested by, Issuer)` |
+| 75 | `cited by` | Academic or reference citation | `(Bitcoin Whitepaper, cited by, Ethereum Whitepaper)` |
+| 76 | `reference` | Forward citation or mention | `(Ethereum Whitepaper, reference, Bitcoin Whitepaper)` |
+| 77 | `evidenced by` | Supporting proof or data | `(Claim, evidenced by, On-chain Proof)` |
+| 78 | `disputed by` | Challenge to a claim | `(Claim, disputed by, Counter-evidence)` |
+| 79 | `confirmed by` | Corroboration of a claim | `(Claim, confirmed by, Independent Source)` |
 
-### Temporal and Lifecycle (83-88)
+### Temporal and Lifecycle (80-85)
 
 | # | Predicate | Intent | Typical Triple Pattern |
 |---|---|---|---|
-| 83 | `preceded by` | Temporal ordering | `(Merge, preceded by, Beacon Chain launch)` |
-| 84 | `followed by` | Forward temporal link | `(Beacon Chain launch, followed by, Merge)` |
-| 85 | `enabled by` | Causal enablement | `(DeFi Summer, enabled by, Compound governance)` |
-| 86 | `triggered` | Causal initiation | `(Terra collapse, triggered, Contagion)` |
-| 87 | `deprecated by` | Formal deprecation | `(ERC-20 approve, deprecated by, ERC-20 permit)` |
-| 88 | `replaced by` | Full substitution | `(Sushiswap Chef, replaced by, MasterChefV2)` |
+| 80 | `preceded by` | Temporal ordering | `(Merge, preceded by, Beacon Chain launch)` |
+| 81 | `followed by` | Forward temporal link | `(Beacon Chain launch, followed by, Merge)` |
+| 82 | `enabled by` | Causal enablement | `(DeFi Summer, enabled by, Compound governance)` |
+| 83 | `triggered` | Causal initiation | `(Terra collapse, triggered, Contagion)` |
+| 84 | `deprecated by` | Formal deprecation | `(ERC-20 approve, deprecated by, ERC-20 permit)` |
+| 85 | `replaced by` | Full substitution | `(Sushiswap Chef, replaced by, MasterChefV2)` |
 
-### Governance and Policy (89-94)
+### Governance and Policy (86-91)
 
 | # | Predicate | Intent | Typical Triple Pattern |
 |---|---|---|---|
-| 89 | `voted for` | Governance vote in favor | `(Alice, voted for, Proposal 42)` |
-| 90 | `voted against` | Governance vote against | `(Alice, voted against, Proposal 43)` |
-| 91 | `delegated to` | Governance delegation | `(Alice, delegated to, Bob)` |
-| 92 | `proposed` | Proposal authorship | `(Alice, proposed, EIP-7702)` |
-| 93 | `regulated by` | Regulatory jurisdiction | `(USDC, regulated by, SEC)` |
-| 94 | `compliant with` | Regulatory compliance | `(Exchange X, compliant with, MiCA)` |
+| 86 | `voted for` | Governance vote in favor | `(I, voted for, Proposal 42)` |
+| 87 | `voted against` | Governance vote against | `(I, voted against, Proposal 43)` |
+| 88 | `delegated to` | Governance delegation | `(I, delegated to, Bob)` |
+| 89 | `proposed` | Proposal authorship | `(Alice, proposed, EIP-7702)` |
+| 90 | `regulated by` | Regulatory jurisdiction | `(USDC, regulated by, SEC)` |
+| 91 | `compliant with` | Regulatory compliance | `(Exchange X, compliant with, MiCA)` |
 
-### Economic and Market (95-100)
+### Economic and Market (92-97)
 
 | # | Predicate | Intent | Typical Triple Pattern |
 |---|---|---|---|
-| 95 | `backed by` | Collateral or backing relationship | `(DAI, backed by, ETH)` |
-| 96 | `pegged to` | Price peg relationship | `(USDC, pegged to, USD)` |
-| 97 | `listed on` | Exchange or marketplace listing | `(ETH, listed on, Coinbase)` |
-| 98 | `sponsored by` | Financial sponsorship | `(Devcon, sponsored by, Ethereum Foundation)` |
-| 99 | `rewards` | Incentive distribution | `(Aave, rewards, Liquidity Providers)` |
-| 100 | `staked in` | Staking relationship | `(Alice, staked in, Ethereum Beacon Chain)` |
+| 92 | `backed by` | Collateral or backing relationship | `(DAI, backed by, ETH)` |
+| 93 | `pegged to` | Price peg relationship | `(USDC, pegged to, USD)` |
+| 94 | `listed on` | Exchange or marketplace listing | `(ETH, listed on, Coinbase)` |
+| 95 | `sponsored by` | Financial sponsorship | `(Devcon, sponsored by, Ethereum Foundation)` |
+| 96 | `reward` | Incentive distribution | `(Aave, reward, Liquidity Providers)` |
+| 97 | `staked in` | Staking relationship | `(I, staked in, Ethereum Beacon Chain)` |
 
 ---
 
@@ -182,9 +181,9 @@ This table maps Schema.org Action types to Intuition predicate strings. The Acti
 
 | Schema.org Action | Intuition Predicate | Notes |
 |---|---|---|
-| `FollowAction` | `follows` | Unidirectional, active interest. Schema.org distinguishes this from SubscribeAction (passive) but that distinction belongs at the app layer. |
+| `FollowAction` | `follow` | Unidirectional, active interest. Schema.org distinguishes this from SubscribeAction (passive) but that distinction belongs at the app layer. |
 | `BefriendAction` | `connected with` | Reciprocal connection. Not in the top 50 — most on-chain graphs are directional. If needed, model as two directional triples. |
-| `SubscribeAction` | `follows` | Schema.org treats this as passive reception vs active polling. In a knowledge graph, both are "follows". Product behavior (push vs pull) is app-specific. |
+| `SubscribeAction` | `follow` | Schema.org treats this as passive reception vs active polling. In a knowledge graph, both are "follow". Product behavior (push vs pull) is app-specific. |
 | `JoinAction` | `member of` | The triple records the resulting state, not the join event. |
 | `LeaveAction` | *(none)* | Leaving is the absence of the `member of` triple or a counter-triple. Not a standalone predicate. |
 | `RegisterAction` | *(none)* | Registration is a one-time event, not a durable relationship. |
@@ -196,18 +195,18 @@ This table maps Schema.org Action types to Intuition predicate strings. The Acti
 
 | Schema.org Action | Intuition Predicate | Notes |
 |---|---|---|
-| `ReactAction` | `likes` | Lightweight positive signal. Schema.org's LikeAction is a sub-type of ReactAction. |
+| `ReactAction` | `like` | Lightweight positive signal. Schema.org's LikeAction is a sub-type of ReactAction. |
 | `ReviewAction` | `reviewed` | The triple asserts the review relationship. Review content lives in the object atom or enrichment. |
-| `EndorseAction` | `endorses` | Stronger than `likes`. Schema.org places this under AssessAction. |
+| `EndorseAction` | `endorse` | Stronger than `like`. Schema.org places this under AssessAction. |
 | `ChooseAction` | *(none)* | Selection is a transient decision, not a graph relationship. |
 | `IgnoreAction` | `blocked` | Closest durable analog. `blocked` is the on-chain record of exclusion. |
-| `DislikeAction` | `distrusts` | Negative assessment. `distrusts` is more useful in a reputation graph than a generic "dislike". |
+| `DislikeAction` | `distrust` | Negative assessment. `distrust` is more useful in a reputation graph than a generic "dislike". |
 
 ### OrganizeAction Family
 
 | Schema.org Action | Intuition Predicate | Notes |
 |---|---|---|
-| `BookmarkAction` | `contains` | Bookmarking is adding to a personal collection. Model as `(my_collection, contains, item)`. |
+| `BookmarkAction` | `contain` | Bookmarking is adding to a personal collection. Model as `(my_collection, contain, item)`. |
 | `PlanAction` | *(none)* | Planning is temporal, not a graph relationship. |
 | `AllocateAction` | *(none)* | Resource allocation is transactional. |
 | `ApplyAction` | *(none)* | Application is an event. |
@@ -241,7 +240,7 @@ This table maps Schema.org Action types to Intuition predicate strings. The Acti
 
 | Schema.org Action | Intuition Predicate | Notes |
 |---|---|---|
-| `WinAction` | `outperforms` | Durable performance superiority, not a single-event win. |
+| `WinAction` | `outperform` | Durable performance superiority, not a single-event win. |
 | `LoseAction` | `worse than` | Relative positioning in the graph. |
 | `TieAction` | `equivalent to` | Functional parity assertion. |
 
@@ -249,8 +248,8 @@ This table maps Schema.org Action types to Intuition predicate strings. The Acti
 
 | Schema.org Action | Intuition Predicate | Notes |
 |---|---|---|
-| `ReplaceAction` | `replaced by` / `supersedes` | Forward and backward version links. The triple records the resulting state. |
-| `AddAction` | `contains` | Adding to a collection maps to the existing containment predicate. |
+| `ReplaceAction` | `replaced by` / `supersede` | Forward and backward version links. The triple records the resulting state. |
+| `AddAction` | `contain` | Adding to a collection maps to the existing containment predicate. |
 | `DeleteAction` | *(none)* | Deletion is the absence of a triple, not a predicate. |
 
 ### Schema.org Property Mappings (Non-Action)
@@ -264,16 +263,16 @@ Many predicates in 51-100 map more naturally to Schema.org properties than to Ac
 | `schema:award` | `certified by` | Credential attestation maps loosely. |
 | `schema:hasCredential` | `certified by` | Direct credential link. |
 | `schema:isRelatedTo` | `related` (existing auxiliary) | Broad association when nothing more specific fits. |
-| `schema:competitor` | `competes with` | Direct market competition. |
+| `schema:competitor` | `compete with` | Direct market competition. |
 | `schema:predecessorOf` | `predecessor of` | Version lineage. |
 | `schema:successorOf` | `successor of` | Forward version link. |
-| `schema:citation` | `cited by` / `references` | Forward and backward citation links. |
+| `schema:citation` | `cited by` / `reference` | Forward and backward citation links. |
 | `schema:sponsor` | `sponsored by` | Financial sponsorship. |
 | `schema:funder` | `backed by` / `invested in` | Financial backing — `backed by` for collateral, `invested in` for equity. |
-| `schema:teaches` | `teaches` | Knowledge dissemination. |
+| `schema:teaches` | `teach` | Knowledge dissemination. |
 | `schema:learner` | `student of` | Learning relationship. |
 | `schema:legislationAppliedBy` | `regulated by` | Regulatory jurisdiction. |
-| `schema:endorsee` | `endorses` / `supports` | `endorses` for entity quality, `supports` for causes and proposals. |
+| `schema:endorsee` | `endorse` / `support` | `endorse` for entity quality, `support` for causes and proposals. |
 | `Wikidata:P1552 (has quality)` | `bullish on` / `bearish on` / `skeptical of` | Sentiment predicates have no Schema.org equivalent — they are Intuition-native social graph primitives. |
 | `Wikidata:P1269 (facet of)` | `enabled by` / `triggered` | Causal relationships are modeled as directional predicates. |
 
@@ -281,35 +280,23 @@ Many predicates in 51-100 map more naturally to Schema.org properties than to Ac
 
 ## DefinedTerm Atom Schemas
 
-Each entry below proposes the predicate as an off-chain `DefinedTerm` registry entry following the schema conventions in `intuition/data-structures/classifications/defined-term/index.md`. These are for documentation, partner registries, and optional IPFS publication — **not** for use as on-chain atom data.
+Each entry below documents the canonical predicate as a minimal Schema.org `DefinedTerm`. The predicates package uses deterministic inline `DefinedTerm` JSON for canonical atom identity and may publish richer IPFS documents as optional enrichment.
 
 ### Identity and Classification
 
-#### 1. `is`
-
-```json
-{
-  "@context": "https://schema.org/",
-  "@type": "DefinedTerm",
-  "name": "is",
-  "description": "Asserts identity, type membership, or definitional equivalence between subject and object.",
-  "sameAs": ["https://schema.org/additionalType"]
-}
-```
-
-#### 2. `has type`
+#### `has type`
 
 ```json
 {
   "@context": "https://schema.org/",
   "@type": "DefinedTerm",
   "name": "has type",
-  "description": "Classifies the subject under a type or category atom. More specific than 'is' — use when asserting formal classification rather than loose identity.",
+  "description": "Classifies the subject under a formal taxonomy or defined-term object.",
   "sameAs": ["https://www.wikidata.org/wiki/Property:P31"]
 }
 ```
 
-#### 3. `same as`
+#### `same as`
 
 ```json
 {
@@ -321,43 +308,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 4. `alias of`
-
-```json
-{
-  "@context": "https://schema.org/",
-  "@type": "DefinedTerm",
-  "name": "alias of",
-  "description": "Marks the subject as an alternative name or identifier for the object entity. Directional: the subject is the alias, the object is the canonical form.",
-  "sameAs": ["https://schema.org/alternateName"]
-}
-```
-
-#### 5. `instance of`
-
-```json
-{
-  "@context": "https://schema.org/",
-  "@type": "DefinedTerm",
-  "name": "instance of",
-  "description": "Asserts that the subject is a concrete instance of the object class or concept.",
-  "sameAs": ["https://www.wikidata.org/wiki/Property:P31"]
-}
-```
-
-#### 6. `subclass of`
-
-```json
-{
-  "@context": "https://schema.org/",
-  "@type": "DefinedTerm",
-  "name": "subclass of",
-  "description": "Asserts that the subject is a more specific type within the object's broader category.",
-  "sameAs": ["https://www.wikidata.org/wiki/Property:P279", "https://www.w3.org/2000/01/rdf-schema#subClassOf"]
-}
-```
-
-#### 7. `has tag`
+#### `has tag`
 
 ```json
 {
@@ -369,80 +320,80 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 8. `has category`
+#### `has category`
 
 ```json
 {
   "@context": "https://schema.org/",
   "@type": "DefinedTerm",
   "name": "has category",
-  "description": "Places the subject within a broader categorical grouping. More formal than tags — use for structured taxonomies rather than free-form labeling.",
+  "description": "Places the subject in a product-level browsable category for user-facing discovery and filtering.",
   "sameAs": ["https://schema.org/category"]
 }
 ```
 
 ### Social and Reputation
 
-#### 9. `follows`
+#### `follow`
 
 ```json
 {
   "@context": "https://schema.org/",
   "@type": "DefinedTerm",
-  "name": "follows",
+  "name": "follow",
   "description": "The subject chooses to subscribe to or track updates from the object entity. Unidirectional and non-reciprocal.",
   "sameAs": ["https://schema.org/FollowAction"]
 }
 ```
 
-#### 10. `likes`
+#### `like`
 
 ```json
 {
   "@context": "https://schema.org/",
   "@type": "DefinedTerm",
-  "name": "likes",
+  "name": "like",
   "description": "Expresses lightweight positive endorsement of the object by the subject.",
   "sameAs": ["https://schema.org/LikeAction"]
 }
 ```
 
-#### 11. `endorses`
+#### `endorse`
 
 ```json
 {
   "@context": "https://schema.org/",
   "@type": "DefinedTerm",
-  "name": "endorses",
+  "name": "endorse",
   "description": "A stronger-than-like signal indicating the subject publicly supports or vouches for the object's quality or legitimacy.",
   "sameAs": ["https://schema.org/EndorseAction"]
 }
 ```
 
-#### 12. `trusts`
+#### `trust`
 
 ```json
 {
   "@context": "https://schema.org/",
   "@type": "DefinedTerm",
-  "name": "trusts",
+  "name": "trust",
   "description": "The subject asserts positive trust in the object. A first-class reputation primitive for web-of-trust graphs."
 }
 ```
 
-#### 13. `distrusts`
+#### `distrust`
 
 ```json
 {
   "@context": "https://schema.org/",
   "@type": "DefinedTerm",
-  "name": "distrusts",
-  "description": "The subject asserts negative trust in the object. The inverse of 'trusts' — enables negative reputation signals.",
+  "name": "distrust",
+  "description": "The subject asserts negative trust in the object. The inverse of 'trust' — enables negative reputation signals.",
   "sameAs": ["https://schema.org/DislikeAction"]
 }
 ```
 
-#### 14. `reviewed`
+#### `reviewed`
 
 ```json
 {
@@ -454,18 +405,18 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 15. `recommended`
+#### `recommend`
 
 ```json
 {
   "@context": "https://schema.org/",
   "@type": "DefinedTerm",
-  "name": "recommended",
-  "description": "The subject actively recommends the object to others in the ecosystem. Stronger than 'likes', weaker than 'endorses'."
+  "name": "recommend",
+  "description": "The subject actively recommends the object to others in the ecosystem. Stronger than 'like', weaker than 'endorse'."
 }
 ```
 
-#### 16. `reported`
+#### `reported`
 
 ```json
 {
@@ -476,7 +427,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 17. `blocked`
+#### `blocked`
 
 ```json
 {
@@ -488,32 +439,44 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 18. `vouches for`
+#### `vouch for`
 
 ```json
 {
   "@context": "https://schema.org/",
   "@type": "DefinedTerm",
-  "name": "vouches for",
+  "name": "vouch for",
   "description": "The subject stakes personal credibility on the object's identity, quality, or claims. A reputation primitive stronger than endorsement."
 }
 ```
 
 ### Curation and Containment
 
-#### 19. `contains`
+#### `contain`
 
 ```json
 {
   "@context": "https://schema.org/",
   "@type": "DefinedTerm",
-  "name": "contains",
+  "name": "contain",
   "description": "The subject collection or container includes the object as a member or entry.",
   "sameAs": ["https://schema.org/hasPart"]
 }
 ```
 
-#### 20. `curated by`
+#### `listed in`
+
+```json
+{
+  "@context": "https://schema.org/",
+  "@type": "DefinedTerm",
+  "name": "listed in",
+  "description": "The subject item appears as an entry within the object collection, stack, or curated list.",
+  "sameAs": ["https://schema.org/isPartOf"]
+}
+```
+
+#### `curated by`
 
 ```json
 {
@@ -525,7 +488,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 21. `pinned in`
+#### `pinned in`
 
 ```json
 {
@@ -536,7 +499,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 22. `featured in`
+#### `featured in`
 
 ```json
 {
@@ -548,7 +511,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 23. `ranked above`
+#### `ranked above`
 
 ```json
 {
@@ -559,19 +522,19 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 24. `depends on`
+#### `depend on`
 
 ```json
 {
   "@context": "https://schema.org/",
   "@type": "DefinedTerm",
-  "name": "depends on",
+  "name": "depend on",
   "description": "The subject requires or relies on the object to function or exist.",
   "sameAs": ["https://schema.org/requirements"]
 }
 ```
 
-#### 25. `alternative to`
+#### `alternative to`
 
 ```json
 {
@@ -585,7 +548,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 
 ### Authorship and Contribution
 
-#### 26. `created by`
+#### `created by`
 
 ```json
 {
@@ -597,7 +560,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 27. `authored by`
+#### `authored by`
 
 ```json
 {
@@ -609,7 +572,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 28. `contributed to`
+#### `contributed to`
 
 ```json
 {
@@ -621,7 +584,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 29. `forked from`
+#### `forked from`
 
 ```json
 {
@@ -632,7 +595,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 30. `derived from`
+#### `derived from`
 
 ```json
 {
@@ -644,7 +607,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 31. `inspired by`
+#### `inspired by`
 
 ```json
 {
@@ -657,7 +620,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 
 ### Metadata and Linking
 
-#### 32. `linked account`
+#### `linked account`
 
 ```json
 {
@@ -669,7 +632,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 33. `url`
+#### `url`
 
 ```json
 {
@@ -681,7 +644,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 34. `imgUrl`
+#### `imgUrl`
 
 ```json
 {
@@ -693,7 +656,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 35. `has description`
+#### `has description`
 
 ```json
 {
@@ -705,7 +668,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 36. `has source`
+#### `has source`
 
 ```json
 {
@@ -717,7 +680,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 37. `published at`
+#### `published at`
 
 ```json
 {
@@ -729,7 +692,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 38. `located in`
+#### `located in`
 
 ```json
 {
@@ -741,7 +704,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 39. `available on`
+#### `available on`
 
 ```json
 {
@@ -755,7 +718,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 
 ### Affiliation and Membership
 
-#### 40. `member of`
+#### `member of`
 
 ```json
 {
@@ -767,7 +730,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 41. `employed by`
+#### `employed by`
 
 ```json
 {
@@ -779,7 +742,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 42. `founded`
+#### `founded`
 
 ```json
 {
@@ -791,7 +754,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 43. `affiliated with`
+#### `affiliated with`
 
 ```json
 {
@@ -803,7 +766,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 44. `partner of`
+#### `partner of`
 
 ```json
 {
@@ -815,7 +778,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 45. `invested in`
+#### `invested in`
 
 ```json
 {
@@ -829,19 +792,19 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 
 ### Domain-Specific Knowledge
 
-#### 46. `uses`
+#### `use`
 
 ```json
 {
   "@context": "https://schema.org/",
   "@type": "DefinedTerm",
-  "name": "uses",
+  "name": "use",
   "description": "The subject utilizes, integrates, or depends on the object tool, technology, or resource.",
   "sameAs": ["https://schema.org/usesDevice"]
 }
 ```
 
-#### 47. `compatible with`
+#### `compatible with`
 
 ```json
 {
@@ -853,7 +816,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 48. `governed by`
+#### `governed by`
 
 ```json
 {
@@ -864,7 +827,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 49. `priced in`
+#### `priced in`
 
 ```json
 {
@@ -876,77 +839,77 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 50. `implements`
+#### `implement`
 
 ```json
 {
   "@context": "https://schema.org/",
   "@type": "DefinedTerm",
-  "name": "implements",
+  "name": "implement",
   "description": "The subject contract, application, or system implements the object standard, specification, or interface."
 }
 ```
 
 ### Sentiment and Opinion
 
-#### 51. `agrees with`
+#### `agree with`
 
 ```json
 {
   "@context": "https://schema.org/",
   "@type": "DefinedTerm",
-  "name": "agrees with",
+  "name": "agree with",
   "description": "The subject's position aligns with the object claim, proposal, or stance.",
   "sameAs": ["https://schema.org/AgreeAction"]
 }
 ```
 
-#### 52. `disagrees with`
+#### `disagree with`
 
 ```json
 {
   "@context": "https://schema.org/",
   "@type": "DefinedTerm",
-  "name": "disagrees with",
+  "name": "disagree with",
   "description": "The subject's position opposes the object claim, proposal, or stance.",
   "sameAs": ["https://schema.org/DisagreeAction"]
 }
 ```
 
-#### 53. `supports`
+#### `support`
 
 ```json
 {
   "@context": "https://schema.org/",
   "@type": "DefinedTerm",
-  "name": "supports",
-  "description": "The subject actively backs the object cause, proposal, or initiative. Broader than 'endorses' — applies to movements and policies, not just entities."
+  "name": "support",
+  "description": "The subject actively backs the object cause, proposal, or initiative. Broader than 'endorse' — applies to movements and policies, not just entities."
 }
 ```
 
-#### 54. `opposes`
+#### `oppose`
 
 ```json
 {
   "@context": "https://schema.org/",
   "@type": "DefinedTerm",
-  "name": "opposes",
-  "description": "The subject actively resists or campaigns against the object cause, proposal, or initiative. The inverse of 'supports'."
+  "name": "oppose",
+  "description": "The subject actively resists or campaigns against the object cause, proposal, or initiative. The inverse of 'support'."
 }
 ```
 
-#### 55. `skeptical of`
+#### `skeptical of`
 
 ```json
 {
   "@context": "https://schema.org/",
   "@type": "DefinedTerm",
   "name": "skeptical of",
-  "description": "The subject expresses cautious doubt about the object without fully rejecting it. Weaker than 'distrusts' or 'opposes'."
+  "description": "The subject expresses cautious doubt about the object without fully rejecting it. Weaker than 'distrust' or 'oppose'."
 }
 ```
 
-#### 56. `bullish on`
+#### `bullish on`
 
 ```json
 {
@@ -957,7 +920,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 57. `bearish on`
+#### `bearish on`
 
 ```json
 {
@@ -968,7 +931,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 58. `neutral on`
+#### `neutral on`
 
 ```json
 {
@@ -981,7 +944,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 
 ### Comparison and Ranking
 
-#### 59. `better than`
+#### `better than`
 
 ```json
 {
@@ -993,7 +956,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 60. `worse than`
+#### `worse than`
 
 ```json
 {
@@ -1004,7 +967,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 61. `equivalent to`
+#### `equivalent to`
 
 ```json
 {
@@ -1016,42 +979,42 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 62. `competes with`
+#### `compete with`
 
 ```json
 {
   "@context": "https://schema.org/",
   "@type": "DefinedTerm",
-  "name": "competes with",
+  "name": "compete with",
   "description": "The subject and object are direct competitors in the same market or category.",
   "sameAs": ["https://schema.org/competitor"]
 }
 ```
 
-#### 63. `outperforms`
+#### `outperform`
 
 ```json
 {
   "@context": "https://schema.org/",
   "@type": "DefinedTerm",
-  "name": "outperforms",
+  "name": "outperform",
   "description": "The subject demonstrably exceeds the object on measurable criteria. Stronger than 'better than' — implies evidence."
 }
 ```
 
-#### 64. `supersedes`
+#### `supersede`
 
 ```json
 {
   "@context": "https://schema.org/",
   "@type": "DefinedTerm",
-  "name": "supersedes",
+  "name": "supersede",
   "description": "The subject is the designated replacement for the object. Implies the object is deprecated or obsolete.",
   "sameAs": ["https://schema.org/supersededBy"]
 }
 ```
 
-#### 65. `predecessor of`
+#### `predecessor of`
 
 ```json
 {
@@ -1063,7 +1026,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 66. `successor of`
+#### `successor of`
 
 ```json
 {
@@ -1077,7 +1040,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 
 ### Knowledge and Expertise
 
-#### 67. `expert in`
+#### `expert in`
 
 ```json
 {
@@ -1089,7 +1052,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 68. `learned from`
+#### `learned from`
 
 ```json
 {
@@ -1100,19 +1063,19 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 69. `teaches`
+#### `teach`
 
 ```json
 {
   "@context": "https://schema.org/",
   "@type": "DefinedTerm",
-  "name": "teaches",
+  "name": "teach",
   "description": "The subject actively disseminates knowledge about the object topic or skill.",
   "sameAs": ["https://schema.org/teaches"]
 }
 ```
 
-#### 70. `studied`
+#### `studied`
 
 ```json
 {
@@ -1124,7 +1087,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 71. `certified by`
+#### `certified by`
 
 ```json
 {
@@ -1136,7 +1099,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 72. `mentor of`
+#### `mentor of`
 
 ```json
 {
@@ -1147,7 +1110,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 73. `student of`
+#### `student of`
 
 ```json
 {
@@ -1158,13 +1121,13 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 74. `speaks`
+#### `speak`
 
 ```json
 {
   "@context": "https://schema.org/",
   "@type": "DefinedTerm",
-  "name": "speaks",
+  "name": "speak",
   "description": "The subject has proficiency in the object language, programming language, or communication system.",
   "sameAs": ["https://schema.org/knowsLanguage"]
 }
@@ -1172,7 +1135,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 
 ### Provenance and Evidence
 
-#### 75. `verified by`
+#### `verified by`
 
 ```json
 {
@@ -1183,7 +1146,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 76. `audited by`
+#### `audited by`
 
 ```json
 {
@@ -1194,7 +1157,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 77. `attested by`
+#### `attested by`
 
 ```json
 {
@@ -1205,7 +1168,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 78. `cited by`
+#### `cited by`
 
 ```json
 {
@@ -1217,19 +1180,19 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 79. `references`
+#### `reference`
 
 ```json
 {
   "@context": "https://schema.org/",
   "@type": "DefinedTerm",
-  "name": "references",
+  "name": "reference",
   "description": "The subject work cites or refers to the object work. A forward citation link — the inverse of 'cited by'.",
   "sameAs": ["https://schema.org/citation"]
 }
 ```
 
-#### 80. `evidenced by`
+#### `evidenced by`
 
 ```json
 {
@@ -1240,7 +1203,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 81. `disputed by`
+#### `disputed by`
 
 ```json
 {
@@ -1251,7 +1214,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 82. `confirmed by`
+#### `confirmed by`
 
 ```json
 {
@@ -1264,7 +1227,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 
 ### Temporal and Lifecycle
 
-#### 83. `preceded by`
+#### `preceded by`
 
 ```json
 {
@@ -1275,7 +1238,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 84. `followed by`
+#### `followed by`
 
 ```json
 {
@@ -1286,7 +1249,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 85. `enabled by`
+#### `enabled by`
 
 ```json
 {
@@ -1297,7 +1260,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 86. `triggered`
+#### `triggered`
 
 ```json
 {
@@ -1308,7 +1271,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 87. `deprecated by`
+#### `deprecated by`
 
 ```json
 {
@@ -1319,7 +1282,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 88. `replaced by`
+#### `replaced by`
 
 ```json
 {
@@ -1333,7 +1296,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 
 ### Governance and Policy
 
-#### 89. `voted for`
+#### `voted for`
 
 ```json
 {
@@ -1345,7 +1308,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 90. `voted against`
+#### `voted against`
 
 ```json
 {
@@ -1357,7 +1320,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 91. `delegated to`
+#### `delegated to`
 
 ```json
 {
@@ -1368,7 +1331,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 92. `proposed`
+#### `proposed`
 
 ```json
 {
@@ -1379,7 +1342,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 93. `regulated by`
+#### `regulated by`
 
 ```json
 {
@@ -1391,7 +1354,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 94. `compliant with`
+#### `compliant with`
 
 ```json
 {
@@ -1404,7 +1367,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 
 ### Economic and Market
 
-#### 95. `backed by`
+#### `backed by`
 
 ```json
 {
@@ -1416,7 +1379,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 96. `pegged to`
+#### `pegged to`
 
 ```json
 {
@@ -1427,7 +1390,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 97. `listed on`
+#### `listed on`
 
 ```json
 {
@@ -1438,7 +1401,7 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 98. `sponsored by`
+#### `sponsored by`
 
 ```json
 {
@@ -1450,18 +1413,18 @@ Each entry below proposes the predicate as an off-chain `DefinedTerm` registry e
 }
 ```
 
-#### 99. `rewards`
+#### `reward`
 
 ```json
 {
   "@context": "https://schema.org/",
   "@type": "DefinedTerm",
-  "name": "rewards",
+  "name": "reward",
   "description": "The subject protocol or program distributes incentives to the object participant class or actor."
 }
 ```
 
-#### 100. `staked in`
+#### `staked in`
 
 ```json
 {
@@ -1478,11 +1441,11 @@ The protocol hashes atom data into a deterministic ID via `keccak256(ATOM_SALT,
 
 ### Option A: Plain String
 
-The predicate atom data is a raw UTF-8 string like `"follows"`.
+The predicate atom data is a raw UTF-8 string like `"follow"`.
 
 ```
-atom data:  "follows"
-atom ID:    keccak256(ATOM_SALT, keccak256(toHex("follows")))
+atom data:  "follow"
+atom ID:    keccak256(ATOM_SALT, keccak256(toHex("follow")))
 ```
 
 | | |
@@ -1499,13 +1462,13 @@ atom ID:    keccak256(ATOM_SALT, keccak256(toHex("follows")))
 The predicate atom data is a JSON document stored directly as the atom bytes.
 
 ```
-atom data:  '{"@context":"https://schema.org/","@type":"DefinedTerm","name":"follows","description":"..."}'
+atom data:  '{"@context":"https://schema.org/","@type":"DefinedTerm","name":"follow","description":"..."}'
 atom ID:    keccak256(ATOM_SALT, keccak256(toHex(json_string)))
 ```
 
 | | |
 |---|---|
-| Determinism | **Fragile.** Key order, whitespace, and Unicode normalization all change the hash. `{"name":"follows","@type":"DefinedTerm"}` and `{"@type":"DefinedTerm","name":"follows"}` produce different atom IDs forever. Requires strict canonical JSON serialization. |
+| Determinism | **Fragile unless canonicalized.** Key order, whitespace, and Unicode normalization all change the hash. `{"name":"follow","@type":"DefinedTerm"}` and `{"@type":"DefinedTerm","name":"follow"}` produce different atom IDs forever unless the SDK uses strict canonical JSON serialization. |
 | Gas cost | 5-10x more bytes than a plain string. |
 | External dependencies | None at read time, but requires a serialization spec at write time. |
 | Self-describing | Yes — carries its own semantic context in the triple. |
@@ -1517,15 +1480,15 @@ atom ID:    keccak256(ATOM_SALT, keccak256(toHex(json_string)))
 Use the full Schema.org Action hierarchy (e.g., `FollowAction`, `EndorseAction`, `BookmarkAction`) as predicate atoms.
 
 ```
-atom data:  '{"@context":"https://schema.org/","@type":"FollowAction","name":"follows"}'
+atom data:  '{"@context":"https://schema.org/","@type":"FollowAction","name":"follow"}'
 ```
 
 | | |
 |---|---|
 | Semantic precision | High. Schema.org distinguishes FollowAction (active polling) from SubscribeAction (passive reception) from BefriendAction (reciprocal). |
-| Protocol fit | **Poor.** Actions are temporal events with `agent`, `startTime`, `endTime`, `actionStatus`. Predicates are durable relationships. A triple `(Alice, follows, Bob)` is a standing fact — not a timestamped event. |
-| Graph fragmentation | If some builders use `FollowAction` and others use `"follows"`, the graph splits. Two predicate atoms, two sets of triples, no interop. |
-| Nuance value | The distinctions Schema.org draws (follow vs subscribe vs befriend) are real, but they matter at the **application layer**, not the **triple layer**. Whether "follows" means push notifications or active polling is a product decision, not a predicate identity question. |
+| Protocol fit | **Poor.** Actions are temporal events with `agent`, `startTime`, `endTime`, `actionStatus`. Predicates are durable relationships. A triple `(Alice, follow, Bob)` is a standing fact — not a timestamped event. |
+| Graph fragmentation | If some builders use `FollowAction` and others use canonical `DefinedTerm` predicate atom data, the graph splits. Two predicate atoms, two sets of triples, no interop. |
+| Nuance value | The distinctions Schema.org draws (follow vs subscribe vs befriend) are real, but they matter at the **application layer**, not the **triple layer**. Whether "follow" means push notifications or active polling is a product decision, not a predicate identity question. |
 
 ### Option D: IPFS-Hosted Document
 
@@ -1543,18 +1506,18 @@ atom ID:    keccak256(ATOM_SALT, keccak256(toHex("ipfs://QmXyz...")))
 | Determinism | The CID is content-addressed, so the same document always produces the same CID. But the atom ID is derived from the CID string, not the document itself — one layer of indirection. |
 | Availability | **Requires IPFS infrastructure.** If pinning lapses and no gateway has the content, the predicate becomes opaque bytes. Builders can't resolve the meaning without the document. |
 | Lookup cost | Every predicate resolution requires an IPFS fetch. Plain strings are self-evident. |
-| Hybrid potential | Could work as an optional enrichment layer — the canonical atom is a plain string, and a separate triple like `(follows_atom, has source, ipfs://QmXyz...)` links it to rich metadata. |
+| Hybrid potential | Works as an optional enrichment layer — the canonical atom can be deterministic inline `DefinedTerm` JSON, and a separate triple like `(follow_atom, has source, ipfs://QmXyz...)` links it to richer metadata. |
 
 ### Recommendation
 
-**Use plain strings as the on-chain predicate atom data.** Publish structured metadata (DefinedTerm schemas, Schema.org Action mappings) as an off-chain registry — in this repo, in SDK docs, and optionally on IPFS for decentralized access.
+**Use deterministic inline `DefinedTerm` JSON as the canonical predicate atom data.** Publish richer structured metadata (Schema.org mappings, usage examples, i18n, and semantic flags) as optional IPFS enrichment or generated SDK metadata without changing the canonical atom identity.
 
 This gives you:
-- Deterministic, gas-cheap, dependency-free atom IDs
-- The same interoperability guarantees as JSON-LD (because the registry maps strings to structured definitions)
-- No graph fragmentation risk from serialization differences
-- Freedom to enrich predicate metadata without changing on-chain identity
+- Self-describing predicate atoms that match the rest of the typed atom model
+- Deterministic atom IDs when the SDK emits canonical JSON bytes
+- No graph fragmentation risk from ad hoc plain strings or Schema.org Action variants
+- Freedom to enrich predicate metadata without changing canonical atom identity
 
-The DefinedTerm schemas in this document serve as the registry layer. The plain string list is the source of truth for on-chain atom creation.
+The generated predicates package remains the source of truth for canonical atom creation; this document explains the semantics and partner-facing modeling guidance.
 
 ---
diff --git a/predicates/2-predicate-usage-by-entity-type.md b/predicates/2-predicate-usage-by-entity-type.md
index 7ddd6bf..552a966 100644
--- a/predicates/2-predicate-usage-by-entity-type.md
+++ b/predicates/2-predicate-usage-by-entity-type.md
@@ -100,7 +100,7 @@ Because predicates read as `(I, predicate, object)`, verb predicates must use **
 
 For attributive triples like `(Aave, use, Chainlink)`, the base form reads slightly differently than English prose ("Aave uses Chainlink"), but predicates are **relationship labels**, not sentences. Base form is standard in ontology design (RDF, Wikidata) and is the correct choice when `I` is the primary subject pattern.
 
-**SDK backward compatibility:** The current SDK exports `CONTAINS_PREDICATE = 'contains'`, `IS_PREDICATE = 'is'`, etc. Migrating to base form predicates will create new atom IDs (since `"follow"` hashes differently from `"follows"`). This is a planned migration — the old predicates remain valid but the new base-form predicates become canonical going forward.
+**SDK compatibility:** Use the generated constants and atom data from `@0xintuition/predicates`. Do not hand-roll legacy plain strings such as `"contains"`/`"is"` or third-person forms such as `"follows"`; they produce different atom IDs and fragment markets.
 
 #### When NOT to Use `I`
 
@@ -119,7 +119,7 @@ These are still depositional (anyone can deposit to agree), but the Subject is o
 **Community-scoped subjects** — a community or role atom instead of `I`:
 
 ```
-(developers, recommends, Foundry)          ← scoped to developers
+(developers, recommend, Foundry)          ← scoped to developers
 (Ethereum community, support, EIP-4844)   ← scoped to a community
 (security researchers, trust, Trail of Bits) ← scoped to a role
 ```
@@ -127,9 +127,9 @@ These are still depositional (anyone can deposit to agree), but the Subject is o
 These create **scoped markets** where the same predicate can have different TVL across different communities. You could have:
 
 ```
-(I, recommends, Foundry)                     ← universal market: 500 ETH
-(developers, recommends, Foundry)             ← developer-scoped: 300 ETH
-(auditors, recommends, Foundry)               ← auditor-scoped: 20 ETH
+(I, recommend, Foundry)                     ← universal market: 500 ETH
+(developers, recommend, Foundry)             ← developer-scoped: 300 ETH
+(auditors, recommend, Foundry)               ← auditor-scoped: 20 ETH
 ```
 
 This is a valid extension pattern but should be used sparingly. Each community subject fragments the market. The universal `I` market should always exist as the primary signal; scoped markets are supplementary.
@@ -260,10 +260,9 @@ These use specific entity Subjects. The market is about whether the claim is TRU
 
 | Predicate | Example Triple | What Deposits Mean |
 |---|---|---|
-| `is` | `(Ethereum, is, blockchain)` | "I agree with this classification" |
-| `has type` | `(Uniswap, has type, DEX)` | "I agree with this type assignment" |
-| `instance of` | `(USDC, instance of, stablecoin)` | "I agree USDC is a stablecoin" |
-| `subclass of` | `(DEX, subclass of, exchange)` | "I agree with this taxonomy" |
+| `has type` | `(Uniswap, has type, Decentralized Exchange)` | "I agree with this formal type assignment" |
+| `has category` | `(Uniswap, has category, DeFi)` | "I agree with this product-level category" |
+| `has tag` | `(Aave, has tag, lending)` | "I agree with this free-form tag" |
 | `same as` | `(ETH, same as, Ether)` | "I agree these are the same entity" |
 | `created by` | `(Ethereum, created by, Vitalik)` | "I agree with this attribution" |
 | `authored by` | `(Whitepaper, authored by, Satoshi)` | "I agree with this authorship claim" |
@@ -359,12 +358,10 @@ A human identity — the most relationship-rich entity type in a social knowledg
 
 | Predicate | Expected Object Type | Example Triple | Priority |
 |---|---|---|---|
-| `is` | `DefinedTerm` | `(Vitalik, is, researcher)` | core |
 | `has type` | `DefinedTerm` | `(Vitalik, has type, public figure)` | common |
 | `has tag` | `DefinedTerm` | `(Alice, has tag, Solidity developer)` | core |
 | `has category` | `DefinedTerm` | `(Alice, has category, builder)` | common |
 | `same as` | `Person` | `(vitalik.eth, same as, Vitalik Buterin)` | common |
-| `alias of` | `Person` | `(V, alias of, Vitalik Buterin)` | optional |
 | `linked account` | `SocialMediaAccount` | `(Alice, linked account, x.com/alice_eth)` | core |
 | `url` | `URL` | `(Alice, url, alice.xyz)` | common |
 | `imgUrl` | `ImageURL` | `(Alice, imgUrl, alice-avatar.png)` | common |
@@ -402,7 +399,7 @@ All opinion predicates should use the depositional pattern. The whole point is t
 | `bearish on` | `Any` | `(I, bearish on, Memecoins)` | Aggregate bearish conviction | common |
 | `neutral on` | `Any` | `(I, neutral on, L2 wars)` | Explicit fence-sitting count | optional |
 | `reviewed` | `SoftwareSourceCode` / `Product` / `Thing` | `(I, reviewed, Uniswap v4)` | Number of reviewers + conviction weight | common |
-| `recommended` | `Any` | `(I, recommended, Hardhat)` | Recommendation strength | common |
+| `recommend` | `Any` | `(I, recommend, Hardhat)` | Recommendation strength | common |
 
 ### Professional and Knowledge (Hybrid)
 
@@ -452,7 +449,6 @@ A company, foundation, DAO, protocol team, or any collective entity.
 
 | Predicate | Expected Object Type | Example Triple | Priority |
 |---|---|---|---|
-| `is` | `DefinedTerm` | `(Uniswap Labs, is, DeFi company)` | core |
 | `has type` | `DefinedTerm` | `(Ethereum Foundation, has type, non-profit)` | core |
 | `has tag` | `DefinedTerm` | `(Aave, has tag, lending)` | core |
 | `has category` | `DefinedTerm` | `(Chainlink, has category, oracle)` | common |
@@ -506,7 +502,6 @@ A protocol, dApp, library, framework, or any code-based project.
 
 | Predicate | Expected Object Type | Example Triple | Priority |
 |---|---|---|---|
-| `is` | `DefinedTerm` | `(Uniswap, is, DEX)` | core |
 | `has type` | `DefinedTerm` | `(MetaMask, has type, wallet)` | core |
 | `has tag` | `DefinedTerm` | `(Aave, has tag, lending)` | core |
 | `has category` | `DefinedTerm` | `(Hardhat, has category, developer tools)` | common |
@@ -576,11 +571,9 @@ A fungible token on an EVM chain.
 
 | Predicate | Expected Object Type | Example Triple | Priority |
 |---|---|---|---|
-| `is` | `DefinedTerm` | `(USDC, is, stablecoin)` | core |
 | `has type` | `DefinedTerm` | `(UNI, has type, governance token)` | core |
 | `has tag` | `DefinedTerm` | `(AAVE, has tag, DeFi)` | core |
 | `has category` | `DefinedTerm` | `(WBTC, has category, wrapped asset)` | common |
-| `instance of` | `DefinedTerm` | `(USDC, instance of, stablecoin)` | common |
 | `url` | `URL` | `(USDC, url, circle.com/usdc)` | common |
 | `imgUrl` | `ImageURL` | `(ETH, imgUrl, eth-diamond.svg)` | common |
 | `has description` | `String` | `(UNI, has description, "Governance token of the Uniswap protocol")` | common |
@@ -620,7 +613,6 @@ A conference, hackathon, governance event, or notable occurrence.
 
 | Predicate | Expected Object Type | Example Triple | Priority |
 |---|---|---|---|
-| `is` | `DefinedTerm` | `(Devcon, is, conference)` | core |
 | `has type` | `DefinedTerm` | `(ETHDenver, has type, hackathon)` | core |
 | `has tag` | `DefinedTerm` | `(Devcon, has tag, Ethereum)` | core |
 | `located in` | `Location` | `(Devcon, located in, Bangkok)` | core |
@@ -660,7 +652,6 @@ An article, whitepaper, blog post, research paper, or written work.
 
 | Predicate | Expected Object Type | Example Triple | Priority |
 |---|---|---|---|
-| `is` | `DefinedTerm` | `(Bitcoin Whitepaper, is, whitepaper)` | core |
 | `has type` | `DefinedTerm` | `(EIP-4844, has type, improvement proposal)` | core |
 | `has tag` | `DefinedTerm` | `(Bitcoin Whitepaper, has tag, cryptography)` | core |
 | `url` | `URL` | `(Bitcoin Whitepaper, url, bitcoin.org/bitcoin.pdf)` | core |
@@ -705,7 +696,6 @@ A physical or digital product, hardware device, or consumer good.
 
 | Predicate | Expected Object Type | Example Triple | Priority |
 |---|---|---|---|
-| `is` | `DefinedTerm` | `(Ledger Nano X, is, hardware wallet)` | core |
 | `has type` | `DefinedTerm` | `(Ledger Nano X, has type, cold storage)` | core |
 | `has tag` | `DefinedTerm` | `(Ledger, has tag, security)` | core |
 | `url` | `URL` | `(Ledger Nano X, url, ledger.com)` | common |
@@ -735,7 +725,6 @@ Collections are curated groups of atoms. They may represent watchlists, director
 
 | Predicate | Expected Object Type | Example Triple | Priority |
 |---|---|---|---|
-| `is` | `DefinedTerm` | `(DeFi Blue Chips, is, watchlist)` | core |
 | `has type` | `DefinedTerm` | `(DeFi Blue Chips, has type, curated list)` | common |
 | `has tag` | `DefinedTerm` | `(Layer 1 Watchlist, has tag, crypto)` | core |
 | `has description` | `String` | `(DeFi Blue Chips, has description, "Top DeFi protocols by TVL")` | common |
@@ -769,7 +758,6 @@ A geographic place, city, country, or virtual region.
 
 | Predicate | Expected Object Type | Example Triple | Priority |
 |---|---|---|---|
-| `is` | `DefinedTerm` | `(Berlin, is, city)` | core |
 | `has type` | `DefinedTerm` | `(Crypto Valley, has type, tech hub)` | common |
 | `has tag` | `DefinedTerm` | `(Zug, has tag, crypto-friendly)` | common |
 | `url` | `URL` | `(Crypto Valley, url, cryptovalley.swiss)` | optional |
@@ -787,11 +775,7 @@ A tag, keyword, concept, standard, or categorical label used as an Object in man
 
 | Predicate | Expected Object Type | Example Triple | Priority |
 |---|---|---|---|
-| `is` | `DefinedTerm` | `(DeFi, is, concept)` | common |
-| `subclass of` | `DefinedTerm` | `(DEX, subclass of, exchange)` | common |
-| `instance of` | `DefinedTerm` | `(Uniswap, instance of, DEX)` | common |
 | `same as` | `DefinedTerm` | `(DeFi, same as, decentralized finance)` | common |
-| `alias of` | `DefinedTerm` | `(defi, alias of, DeFi)` | optional |
 | `has description` | `String` | `(ZK proofs, has description, "Zero-knowledge proof systems")` | common |
 | `url` | `URL` | `(ERC-20, url, eips.ethereum.org/EIPS/eip-20)` | optional |
 | `alternative to` | `DefinedTerm` | `(PoS, alternative to, PoW)` | optional |
@@ -809,7 +793,6 @@ A platform account atom linked to an identity.
 
 | Predicate | Expected Object Type | Example Triple | Priority |
 |---|---|---|---|
-| `is` | `DefinedTerm` | `(x.com/alice_eth, is, social account)` | common |
 | `has type` | `DefinedTerm` | `(x.com/alice_eth, has type, X account)` | common |
 | `url` | `URL` | `(x.com/alice_eth, url, x.com/alice_eth)` | core |
 | `imgUrl` | `ImageURL` | `(x.com/alice_eth, imgUrl, alice-profile.jpg)` | optional |
@@ -827,7 +810,6 @@ A deployed contract on an EVM chain.
 
 | Predicate | Expected Object Type | Example Triple | Priority |
 |---|---|---|---|
-| `is` | `DefinedTerm` | `(0xUniRouter, is, router contract)` | core |
 | `has type` | `DefinedTerm` | `(0xUniRouter, has type, DEX router)` | core |
 | `has tag` | `DefinedTerm` | `(0xUniRouter, has tag, DeFi)` | common |
 | `created by` | `Person` / `Organization` | `(0xUniRouter, created by, Uniswap Labs)` | core |
@@ -848,7 +830,6 @@ These predicates work with **any** Subject entity type:
 
 | Predicate | Expected Object Type | Notes |
 |---|---|---|
-| `is` | `DefinedTerm` | Type or identity assertion |
 | `has type` | `DefinedTerm` | Formal classification |
 | `has tag` | `DefinedTerm` | Free-form tagging |
 | `has category` | `DefinedTerm` | Structured taxonomy |
@@ -856,7 +837,6 @@ These predicates work with **any** Subject entity type:
 | `imgUrl` | `ImageURL` | Visual representation |
 | `has description` | `String` | Textual description |
 | `same as` | Same entity type | Cross-representation identity |
-| `alias of` | Same entity type | Alternative name |
 | `contain` | `Any` | Collection membership (when Subject is a container) |
 | `created by` | `Person` / `Organization` | Origin attribution |
 | `like` | `Any` | Lightweight positive signal (when Subject is a Person) |
@@ -1078,7 +1058,7 @@ Alice has fewer delegators but much more capital behind her = whale-backed deleg
 
 **Collection structure (all attributive — these are facts about the collection):**
 ```
-(DeFi Blue Chips, is, curated list)
+(DeFi Blue Chips, has type, curated list)
 (DeFi Blue Chips, has tag, DeFi)
 (DeFi Blue Chips, has description, "Top DeFi protocols by TVL and track record")
 (DeFi Blue Chips, curated by, Alice)
@@ -1093,7 +1073,7 @@ Alice has fewer delegators but much more capital behind her = whale-backed deleg
 ```
 (I, like, DeFi Blue Chips)          — TVL: 50 ETH from 300 depositors
 (I, follow, DeFi Blue Chips)        — TVL: 20 ETH from 150 depositors
-(I, recommended, DeFi Blue Chips)    — TVL: 10 ETH from 40 depositors
+(I, recommend, DeFi Blue Chips)      — TVL: 10 ETH from 40 depositors
 ```
 
 **Ranking items within the collection (depositional — opinion markets):**
@@ -1184,7 +1164,7 @@ These are specific factual claims about Alice. Others deposit to confirm the cla
 
 **Factual triples that inform the debate (attributive):**
 ```
-(Bitcoin, is, cryptocurrency)
+(Bitcoin, has type, cryptocurrency)
 (Bitcoin, created by, Satoshi Nakamoto)
 (Bitcoin, has tag, store of value)
 (Bitcoin, has tag, digital gold)
@@ -1201,7 +1181,7 @@ These are specific factual claims about Alice. Others deposit to confirm the cla
 
 **Attributive facts about the event:**
 ```
-(Devcon 7, is, conference)
+(Devcon 7, has type, conference)
 (Devcon 7, has type, developer conference)
 (Devcon 7, located in, Bangkok)
 (Devcon 7, created by, Ethereum Foundation)
@@ -1215,7 +1195,7 @@ These are specific factual claims about Alice. Others deposit to confirm the cla
 **Depositional engagement signals:**
 ```
 (I, like, Devcon 7)             — TVL: 25 ETH from 500 depositors
-(I, recommended, Devcon 7)       — TVL: 8 ETH from 100 depositors
+(I, recommend, Devcon 7)         — TVL: 8 ETH from 100 depositors
 ```
 
 **Items featured at the event (attributive):**
@@ -1233,8 +1213,6 @@ These are specific factual claims about Alice. Others deposit to confirm the cla
 
 **Attributive facts (all specific to USDC):**
 ```
-(USDC, is, stablecoin)
-(USDC, instance of, stablecoin)
 (USDC, has type, fiat-backed stablecoin)
 (USDC, created by, Circle)
 (USDC, implement, ERC-20)
@@ -1268,7 +1246,7 @@ These are specific factual claims about Alice. Others deposit to confirm the cla
 
 **Attributive facts about Vitalik:**
 ```
-(Vitalik Buterin, is, researcher)
+(Vitalik Buterin, has type, researcher)
 (Vitalik Buterin, has type, public figure)
 (Vitalik Buterin, founded, Ethereum)
 (Vitalik Buterin, founded, Bitcoin Magazine)
@@ -1344,7 +1322,7 @@ The triple already has direction via subject/object ordering. Adding "is followe
 BAD:   (Aave, provides lending on, Ethereum)      ← too specific, one-off predicate
 BAD:   (Aave, is a DeFi lending protocol on, Ethereum)  ← sentence in a predicate
 
-GOOD:  (Aave, is, lending protocol)
+GOOD:  (Aave, has type, lending protocol)
        (Aave, has tag, DeFi)
        (Aave, available on, Ethereum)
 ```
@@ -1414,7 +1392,7 @@ Always check the canonical direction documented in the predicate catalog. The su
 
 **Phase 2 — Factual claims emerge (attributive):**
 ```
-(Wormhole Exploit, is, bridge hack)
+(Wormhole Exploit, has type, bridge hack)
 (Wormhole Exploit, has tag, security incident)
 (Wormhole Bridge, audited by, Neodyme)                    — TVL: 5 ETH (people confirm the audit happened)
 (Wormhole Exploit, evidenced by, etherscan.io/tx/0x...)   — TVL: 20 ETH (people confirm the evidence)
@@ -1445,14 +1423,14 @@ Always check the canonical direction documented in the predicate catalog. The su
 (I, like, Foundry)                 — TVL: 80 ETH from 1,200 depositors
 (Hardhat, better than, Foundry)  — TVL: 15 ETH from 200 depositors
 (Foundry, better than, Hardhat)  — TVL: 50 ETH from 600 depositors
-(I, recommended, Foundry)           — TVL: 30 ETH from 300 depositors
-(I, recommended, Hardhat)           — TVL: 10 ETH from 100 depositors
+(I, recommend, Foundry)             — TVL: 30 ETH from 300 depositors
+(I, recommend, Hardhat)             — TVL: 10 ETH from 100 depositors
 ```
 
 **Attributive context:**
 ```
-(Hardhat, is, development framework)
-(Foundry, is, development framework)
+(Hardhat, has type, development framework)
+(Foundry, has type, development framework)
 (Hardhat, created by, NomicLabs)
 (Foundry, created by, Paradigm)
 (Hardhat, use, JavaScript)
@@ -1499,7 +1477,7 @@ TRICKY:  How do you express "Ethereum is NOT a security"?
 ```
 
 There is no `is not` predicate. Two approaches:
-1. Use the positive claim and let low/no TVL speak: `(Ethereum, is, security)` — if no one deposits, the market has spoken.
+1. Use the positive claim and let low/no TVL speak: `(Ethereum, has type, security)` — if no one deposits, the market has spoken.
 2. Use the counter-market: `(I, agree with, Ethereum is not a security)` and `(I, disagree with, Ethereum is not a security)`.
 
 Option 2 is better because it creates an explicit market. Absence of deposits is ambiguous (maybe no one noticed the triple), but an active market with a strong ratio is unambiguous signal.
diff --git a/predicates/3-predicate-display-and-conjugation.md b/predicates/3-predicate-display-and-conjugation.md
index d3e1a64..eabc2af 100644
--- a/predicates/3-predicate-display-and-conjugation.md
+++ b/predicates/3-predicate-display-and-conjugation.md
@@ -163,7 +163,7 @@ The `conjugates` and `thirdPerson` fields are display metadata. They are never s
 The rendering function takes a predicate's `name` (extracted from the DefinedTerm atom data or from the SDK predicate definitions) and the subject context, and returns the display form:
 
 ```typescript
-import { PREDICATE_DEFS } from '@intuition/predicates';
+import { PREDICATE_DEFS } from '@0xintuition/predicates';
 
 type SubjectContext = 'first-person' | 'singular' | 'plural';
 
@@ -215,8 +215,6 @@ const displayForm = renderPredicate(predicateName, subjectContext);
 When the predicate has an IPFS enrichment document (linked via a `has source` triple or used directly as the atom data in the IPFS URI strategy), the enrichment contains conjugation and localization data for multiple languages:
 
 ```typescript
-import { resolvePredicateEnrichment } from '@intuition/predicate-i18n';
-
 /**
  * Renders a predicate for a specific locale and subject context.
  * Resolves the IPFS enrichment document for i18n labels.
@@ -227,7 +225,7 @@ async function renderPredicateLocalized(
   locale: string,
   subjectContext: SubjectContext
 ): Promise<string> {
-  // Try to resolve i18n from IPFS enrichment
+  // App-specific helper that resolves i18n from IPFS enrichment
   const enrichment = await resolvePredicateEnrichment(predicateName);
 
   if (enrichment?.i18n?.[locale]) {
@@ -314,9 +312,8 @@ These predicates are multi-word phrases, adjective-based, or passive constructio
 
 | Predicate | Why it doesn't conjugate |
 |---|---|
-| `is` | Already works as both base and third-person |
 | `has type`, `has tag`, `has category`, `has description`, `has source` | Fixed compound labels (see `has` anomaly below) |
-| `same as`, `alias of`, `instance of`, `subclass of`, `member of` | Noun/adjective phrases |
+| `same as`, `listed in`, `member of`, `student of`, `mentor of` | Noun/adjective phrases |
 | `employed by`, `affiliated with`, `created by`, `authored by` | Past participle — doesn't change |
 | `audited by`, `verified by`, `certified by`, `governed by`, `regulated by` | Past participle |
 | `backed by`, `pegged to`, `listed on`, `available on` | Past participle / adjective phrase |
@@ -326,7 +323,7 @@ These predicates are multi-word phrases, adjective-based, or passive constructio
 | `expert in`, `linked account`, `predecessor of`, `successor of` | Noun phrase |
 | `student of`, `mentor of`, `partner of` | Noun phrase |
 
-The majority of predicates do not conjugate at all. The conjugation problem only affects active-voice single verbs — roughly 22 out of 100 cataloged predicates.
+The majority of predicates do not conjugate at all. The conjugation problem only affects active-voice single verbs — roughly 22 out of 97 cataloged predicates.
 
 ---
 
diff --git a/predicates/4-predicate-architecture-first-principles.md b/predicates/4-predicate-architecture-first-principles.md
index 8bfc2f3..ae5668a 100644
--- a/predicates/4-predicate-architecture-first-principles.md
+++ b/predicates/4-predicate-architecture-first-principles.md
@@ -2,6 +2,8 @@
 
 This document works from first principles to determine the right architecture for enshrined predicates. It is deliberately not anchored to any prior recommendation. It follows the evidence.
 
+Current implementation note: the predicates package now implements the Approach C outcome from this analysis: canonical predicate atoms use deterministic inline `DefinedTerm` JSON, and the SDK exports precomputed atom IDs such as `FOLLOW_ID`.
+
 ---
 
 ## The Actual Problem
@@ -62,7 +64,7 @@ The question isn't just "string vs IPFS." It's: **should predicates be classifie
 
 ## Four Concrete Approaches
 
-### Approach A: Plain Strings (Current)
+### Approach A: Plain Strings (Legacy Baseline)
 
 Predicate atom data is a raw UTF-8 string.
 
@@ -91,7 +93,7 @@ Interpretation: OK, so 0x123 is a Person named Vitalik, 0x789 is an Organization
 ```
 1. npm install @intuition/sdk
 2. Read SDK docs to learn that "follow" is a predicate
-3. Import FOLLOW constant
+3. Import FOLLOW_ID constant
 4. Use it
 5. Works — but only because the SDK told them what "follow" means
 ```
@@ -99,7 +101,7 @@ Interpretation: OK, so 0x123 is a Person named Vitalik, 0x789 is an Organization
 **What breaks at scale:**
 
 ```
-Partner A reads the SDK, uses FOLLOW constant → atom ID 0x456
+Partner A reads the SDK, uses FOLLOW_ID constant → atom ID 0x456
 Partner B doesn't use the SDK, creates an atom with "Follow" → atom ID 0x999
 Partner C creates an atom with "follow " (trailing space) → atom ID 0xaaa
 
@@ -361,11 +363,11 @@ What does a developer actually do every day?
 
 ```typescript
 // They import a constant and use it. This is the same for ALL approaches.
-import { FOLLOW } from '@intuition/predicates';
-await createTriple({ subject: I_SUBJECT, predicate: FOLLOW, object: vitalikId });
+import { FOLLOW_ID, I_SUBJECT_ID } from '@0xintuition/predicates';
+await createTriple({ subject: I_SUBJECT_ID, predicate: FOLLOW_ID, object: vitalikId });
 ```
 
-The atom data format is invisible to the daily developer. The SDK abstracts it. Whether `FOLLOW` resolves to `"follow"` or `{"@type":"DefinedTerm","name":"follow",...}` doesn't change the import/use pattern.
+The atom data format is invisible to the daily developer. The SDK abstracts it. Whether `FOLLOW_ID` resolves from `"follow"` or `{"@type":"DefinedTerm","name":"follow",...}` doesn't change the import/use pattern.
 
 **Winner: Tie.** All approaches have the same SDK surface.
 
@@ -676,17 +678,17 @@ For 25 launch predicates, this produces 25 DefinedTerm atoms on-chain.
 ### Daily SDK Usage (Unchanged)
 
 ```typescript
-import { FOLLOW, LIKE, TRUST, I_SUBJECT } from '@intuition/predicates';
+import { FOLLOW_ID, LIKE_ID, TRUST_ID, I_SUBJECT_ID } from '@0xintuition/predicates';
 
 // Same as before — developer doesn't care about atom internals
 await createTriple({
-  subject: I_SUBJECT,
-  predicate: FOLLOW,
+  subject: I_SUBJECT_ID,
+  predicate: FOLLOW_ID,
   object: vitalikAtomId
 });
 ```
 
-The SDK exports pre-computed atom IDs. The fact that `FOLLOW` resolves to a DefinedTerm atom ID instead of a plain string atom ID is invisible.
+The SDK exports pre-computed atom IDs. The fact that `FOLLOW_ID` resolves to a DefinedTerm atom ID instead of a plain string atom ID is invisible.
 
 ### Cold-Start Developer (Exploring Chain Data)
 
@@ -738,7 +740,7 @@ User's locale: French
 User action: clicks "Suivre" button on Vitalik's profile
 
 Frontend flow:
-  1. Resolve "follow" predicate → FOLLOW atom ID
+  1. Resolve "follow" predicate → FOLLOW_ID atom ID
   2. Market pattern = depositional → use I_SUBJECT
   3. Find or create (I, follow, Vitalik) triple
   4. User deposits
@@ -788,7 +790,7 @@ If we go with Approach C, the migration from current state is:
 |---|---|---|
 | Atom data: `"follows"` | Atom data: `{"@type":"DefinedTerm","name":"follow",...}` | New atom ID (double migration: base form + DefinedTerm) |
 | No on-chain registry | Registry triples | New triples |
-| SDK: `FOLLOWS_PREDICATE = "follows"` | SDK: `FOLLOW = calculateAtomId(definedTermJson)` | SDK constant change |
+| SDK: `FOLLOWS_PREDICATE = "follows"` | SDK: `FOLLOW_ID = calculateAtomId(definedTermJson)` | SDK constant change |
 | Interpretation: docs only | Interpretation: atom data + 2 triples + off-chain | New architecture |
 
 This is a larger migration than Approach A or B. But it's a one-time cost at launch. And combining the base-form migration with the DefinedTerm migration is cleaner than doing them separately.
diff --git a/predicates/5-predicate-i18n-strategy.md b/predicates/5-predicate-i18n-strategy.md
index 8922d9a..faad8db 100644
--- a/predicates/5-predicate-i18n-strategy.md
+++ b/predicates/5-predicate-i18n-strategy.md
@@ -257,7 +257,7 @@ The rule is simple:
 Input:
 
 ```text
-predicateAtomId = FOLLOW
+predicateAtomId = FOLLOW_ID
 locale = "fr"
 subjectContext = "first-person"
 ```
@@ -265,11 +265,11 @@ subjectContext = "first-person"
 Resolution:
 
 ```text
-1. Read FOLLOW atom data
+1. Read FOLLOW_ID atom data
    → name = "follow"
    → description = "Directional subscription or tracking..."
 
-2. Query localization entries for FOLLOW
+2. Query localization entries for FOLLOW_ID
    → find entry for locale = fr
 
 3. Resolve source
@@ -286,7 +286,7 @@ Resolution:
 If French has not been added yet:
 
 ```text
-1. Read FOLLOW atom data
+1. Read FOLLOW_ID atom data
 2. No localization entry for fr
 3. Fallback to English atom name
    → "follow"
diff --git a/predicates/6-predicate-sdk-implementation-guide.md b/predicates/6-predicate-sdk-implementation-guide.md
index eb321dd..e5bdf58 100644
--- a/predicates/6-predicate-sdk-implementation-guide.md
+++ b/predicates/6-predicate-sdk-implementation-guide.md
@@ -337,21 +337,27 @@ export const PREDICATE_DEFS: Record<string, PredicateDefinition> = {
   },
 
   // --- Identity and Classification ---
-  is: {
-    name: "is",
-    description: "Asserts identity, type membership, or definitional equivalence between subject and object",
+  hasType: {
+    name: "has type",
+    description: "Classifies the subject under a formal taxonomy or defined-term object",
+    marketPattern: "attributive",
+    conjugates: false,
+  },
+  sameAs: {
+    name: "same as",
+    description: "Declares that the subject and object refer to the same real-world entity",
     marketPattern: "attributive",
     conjugates: false,
   },
   hasTag: {
     name: "has tag",
-    description: "Assigns a reusable tag or keyword to the subject for filtering and discovery",
+    description: "Assigns a free-form keyword or tag atom to the subject",
     marketPattern: "attributive",
     conjugates: false,
   },
-  hasType: {
-    name: "has type",
-    description: "Classifies the subject under a formal type or category",
+  hasCategory: {
+    name: "has category",
+    description: "Places the subject in a product-level browsable category",
     marketPattern: "attributive",
     conjugates: false,
   },
@@ -542,14 +548,14 @@ The SDK ships with pre-computed atom IDs for the chosen strategy. The project co
 
 ```typescript
 // For inline JSON strategy:
-export const FOLLOW = calculateAtomId(getInlineAtomData('follow'));
-export const LIKE = calculateAtomId(getInlineAtomData('like'));
-export const TRUST = calculateAtomId(getInlineAtomData('trust'));
+export const FOLLOW_ID = calculateAtomId(getInlineAtomData('follow'));
+export const LIKE_ID = calculateAtomId(getInlineAtomData('like'));
+export const TRUST_ID = calculateAtomId(getInlineAtomData('trust'));
 // ...
 
 // For IPFS strategy (CIDs are fixed after initial upload):
-// export const FOLLOW = calculateAtomId('ipfs://bafyreif7x...');
-// export const LIKE = calculateAtomId('ipfs://bafyreig3m...');
+// export const FOLLOW_ID = calculateAtomId('ipfs://bafyreif7x...');
+// export const LIKE_ID = calculateAtomId('ipfs://bafyreig3m...');
 // ...
 ```
 
@@ -570,13 +576,13 @@ export const I_SUBJECT_ID = calculateAtomId(I_SUBJECT_DATA);
 
 ## Creating Triples
 
-The developer-facing API for creating triples is the same regardless of strategy. The SDK resolves predicate constants to atom IDs internally.
+The developer-facing API for creating triples is the same regardless of strategy. The exported predicate constants are atom IDs for the chosen canonical strategy.
 
 ```typescript
 // Depositional triple: user follows Vitalik
 await createTriple({
   subject: I_SUBJECT_ID,
-  predicate: FOLLOW,
+  predicate: FOLLOW_ID,
   object: vitalikAtomId,
   deposit: parseEther('0.1'),
 });
@@ -584,7 +590,7 @@ await createTriple({
 // Attributive triple: fact about Ethereum
 await createTriple({
   subject: ethereumAtomId,
-  predicate: CREATED_BY,
+  predicate: CREATED_BY_ID,
   object: vitalikAtomId,
   deposit: parseEther('0.01'),
 });
@@ -592,7 +598,7 @@ await createTriple({
 // Collection curation: adding an item
 await createTriple({
   subject: defiBlueChipsAtomId,
-  predicate: CONTAIN,
+  predicate: CONTAIN_ID,
   object: aaveAtomId,
   deposit: parseEther('0.01'),
 });
@@ -712,8 +718,8 @@ for (const [key, def] of Object.entries(PREDICATE_DEFS)) {
   const patternId = def.marketPattern === 'depositional' ? depositionalId
                   : def.marketPattern === 'attributive'  ? attributiveId
                   : comparativeId;
-  await createTriple({ subject: PREDICATE_IDS[key], predicate: HAS_TYPE, object: patternId });
-  await createTriple({ subject: registryId, predicate: CONTAIN, object: PREDICATE_IDS[key] });
+  await createTriple({ subject: PREDICATE_IDS[key], predicate: HAS_TYPE_ID, object: patternId });
+  await createTriple({ subject: registryId, predicate: CONTAIN_ID, object: PREDICATE_IDS[key] });
 }
 ```
 
diff --git a/predicates/7-predicate-integration-partner-guide.md b/predicates/7-predicate-integration-partner-guide.md
index f59090e..6653dea 100644
--- a/predicates/7-predicate-integration-partner-guide.md
+++ b/predicates/7-predicate-integration-partner-guide.md
@@ -9,7 +9,7 @@ For the full predicate catalog and market design theory, see `predicate-analysis
 ## Key Concepts in 60 Seconds
 
 1. **Triples** are `(Subject, Predicate, Object)` — three atoms that form a knowledge claim.
-2. **Predicates** are the relationship between subject and object. They are plain strings stored on-chain.
+2. **Predicates** are the relationship between subject and object. Enshrined predicates are canonical atom IDs derived from deterministic `DefinedTerm` atom data.
 3. **Enshrined predicates** are the canonical predicates supported by the Intuition ecosystem (SDK, indexer, API, frontends).
 4. **The `I` atom** is a singleton atom with data `"I"`. It is the universal subject for first-person claims. When Alice deposits on `(I, follow, Vitalik)`, she is saying "I follow Vitalik."
 5. **Vaults** are created per triple. Deposits express conviction. TVL is the signal.
@@ -69,29 +69,28 @@ Is the depositor making a claim about themselves?
 
 ```typescript
 import {
-  I_SUBJECT,
-  FOLLOW,
-  LIKE,
-  TRUST,
-  DISTRUST,
-  ENDORSE,
-  RECOMMEND,
-  CONTAIN,
-  CURATED_BY,
-  IS,
-  HAS_TAG,
-  HAS_TYPE,
-  HAS_DESCRIPTION,
-  CREATED_BY,
-  SAME_AS,
-  BETTER_THAN,
-  ALTERNATIVE_TO,
-  AGREE_WITH,
-  DISAGREE_WITH,
-  BULLISH_ON,
-  BEARISH_ON,
+  I_SUBJECT_ID,
+  FOLLOW_ID,
+  LIKE_ID,
+  TRUST_ID,
+  DISTRUST_ID,
+  ENDORSE_ID,
+  RECOMMEND_ID,
+  CONTAIN_ID,
+  CURATED_BY_ID,
+  HAS_TAG_ID,
+  HAS_TYPE_ID,
+  HAS_DESCRIPTION_ID,
+  CREATED_BY_ID,
+  SAME_AS_ID,
+  BETTER_THAN_ID,
+  ALTERNATIVE_TO_ID,
+  AGREE_WITH_ID,
+  DISAGREE_WITH_ID,
+  BULLISH_ON_ID,
+  BEARISH_ON_ID,
   // ... see full list in enshrined-predicates-launch-set.md
-} from '@intuition/predicates';
+} from '@0xintuition/predicates';
 ```
 
 ### Creating a Triple
@@ -99,8 +98,8 @@ import {
 ```typescript
 // Depositional: User follows Vitalik
 await createTriple({
-  subject: I_SUBJECT,       // "I"
-  predicate: FOLLOW,         // "follow"
+  subject: I_SUBJECT_ID,     // atom ID for "I"
+  predicate: FOLLOW_ID,      // atom ID for the "follow" DefinedTerm predicate
   object: vitalikAtomId,
   deposit: parseEther('0.1'),
 });
@@ -108,7 +107,7 @@ await createTriple({
 // Attributive: Factual claim about Ethereum
 await createTriple({
   subject: ethereumAtomId,
-  predicate: CREATED_BY,     // "created by"
+  predicate: CREATED_BY_ID,  // atom ID for the "created by" predicate
   object: vitalikAtomId,
   deposit: parseEther('0.01'),
 });
@@ -116,7 +115,7 @@ await createTriple({
 // Collection curation: adding an item to a collection
 await createTriple({
   subject: defiBlueChipsAtomId,
-  predicate: CONTAIN,        // "contain"
+  predicate: CONTAIN_ID,     // atom ID for the "contain" predicate
   object: aaveAtomId,
   deposit: parseEther('0.01'),
 });
@@ -124,7 +123,7 @@ await createTriple({
 // Comparative: Head-to-head opinion
 await createTriple({
   subject: rustAtomId,
-  predicate: BETTER_THAN,    // "better than"
+  predicate: BETTER_THAN_ID, // atom ID for the "better than" predicate
   object: solidityAtomId,
   deposit: parseEther('0.05'),
 });
@@ -132,21 +131,21 @@ await createTriple({
 
 ### Displaying Predicates
 
-Never show the raw predicate string to users. Use the SDK rendering function:
+Never show raw predicate atom data or IDs to users. Use the SDK rendering helpers:
 
 ```typescript
-import { renderPredicate } from '@intuition/predicate-i18n';
+import { renderLocalizedPredicate } from '@0xintuition/predicates';
 
 // "I follow Vitalik"
-renderPredicate('follow', { locale: 'en', subjectContext: 'first-person' });
+renderLocalizedPredicate('follow', { subjectContext: 'first-person' });
 // → "follow"
 
 // "Alice follows Vitalik"
-renderPredicate('follow', { locale: 'en', subjectContext: 'singular' });
+renderLocalizedPredicate('follow', { subjectContext: 'singular' });
 // → "follows"
 
 // Button label
-renderPredicate('follow', { locale: 'en', subjectContext: 'first-person', form: 'displayName' });
+renderLocalizedPredicate('follow', { subjectContext: 'first-person', form: 'displayName' });
 // → "Follow"
 ```
 
@@ -244,8 +243,8 @@ Returns all triples where the entity appears as subject or object.
 ### 1. Fragmenting the market
 
 ```
-BAD:   createTriple({ subject: aliceAtomId, predicate: FOLLOW, object: vitalikAtomId })
-GOOD:  createTriple({ subject: I_SUBJECT,   predicate: FOLLOW, object: vitalikAtomId })
+BAD:   createTriple({ subject: aliceAtomId, predicate: FOLLOW_ID, object: vitalikAtomId })
+GOOD:  createTriple({ subject: I_SUBJECT_ID, predicate: FOLLOW_ID, object: vitalikAtomId })
 ```
 
 If the user is following Vitalik, use `I`. Alice's identity is captured by her deposit address.
@@ -253,9 +252,9 @@ If the user is following Vitalik, use `I`. Alice's identity is captured by her d
 ### 2. Using UI concepts as predicates
 
 ```
-BAD:   createTriple({ subject: I_SUBJECT, predicate: 'bookmark', object: uniswapAtomId })
-BAD:   createTriple({ subject: I_SUBJECT, predicate: 'star',     object: uniswapAtomId })
-GOOD:  createTriple({ subject: I_SUBJECT, predicate: LIKE,       object: uniswapAtomId })
+BAD:   createTriple({ subject: I_SUBJECT_ID, predicate: 'bookmark', object: uniswapAtomId })
+BAD:   createTriple({ subject: I_SUBJECT_ID, predicate: 'star', object: uniswapAtomId })
+GOOD:  createTriple({ subject: I_SUBJECT_ID, predicate: LIKE_ID, object: uniswapAtomId })
 ```
 
 "Bookmark," "star," and "favorite" are UI concepts. They all mean `like` at the semantic level. Your app can render it as a bookmark icon — that's a frontend choice, not a predicate choice.
@@ -264,10 +263,10 @@ GOOD:  createTriple({ subject: I_SUBJECT, predicate: LIKE,       object: uniswap
 
 ```
 BAD:   createTriple({ predicate: 'follows' })   // old third-person form
-GOOD:  createTriple({ predicate: FOLLOW })        // "follow" — base form
+GOOD:  createTriple({ predicate: FOLLOW_ID })    // canonical atom ID for "follow"
 ```
 
-`"follows"` and `"follow"` are different atom IDs. Always use the SDK constants. See `predicate-migration-guide.md`.
+`"follows"` and the canonical `follow` DefinedTerm atom data produce different atom IDs. Always use the SDK constants. See `predicate-migration-guide.md`.
 
 ### 4. Creating custom predicates for covered concepts