Library / First Principles Framework (FPF) - Core Conceptual Specification
Jump to passage
In this reading

Link to current text

Published source confirmed at last check

Source changed 2026-10-03 05:29:54 UTC · snapshot created 2026-10-03 05:30:57 UTC · last check 2026-10-03 06:15:20 UTC

A.6.9:5.1 - System archetype: IAM User and CRM Customer

The ambiguous sentence is: “An IAM User is the same as a CRM Customer.”

Treat this as a schematic hypothetical illustration. The abbreviated endpoint readings are:

  • SenseCell(IAMRoleReferenceScheme-v3, User-human-or-service-account-role);
  • SenseCell(CRMRoleReferenceScheme-v5, Customer-commercial-party-role).

These sketches name the intended scheme editions and sense readings. A full case must still resolve each <ReferenceScheme by value, LocalExpression, LocalSenseClaim> value, with User and Customer as the respective local expressions.

For the illustration, assume that the local meanings share some human cases, while service accounts and prospects provide cases excluded by the opposite reading. These are additional hypothetical premises, not facts recovered from the ambiguous sentence. Profile P-IAM-CRM-OVERLAP-v2 states the symmetric Partial-overlap relation, exact endpoint readings, overlap and difference conditions, edition basis, truth condition, and required membership evidence. The example additionally stipulates that the profile applies and its predicate is true, and therefore uses b-iam-crm as an obtaining Bridge. The profile description lists what a full test needs; it does not supply that test or its evidence.

Now state the use separately. Dashboard team proposes u-actor-label: render IAM users as “actors” in a CRM-oriented comparison. Direction d-iam-crm is IAM-to-CRM dashboard reading. Rule r-actor keeps account eligibility and customer eligibility visible as separate columns. Tolerance t-actor allows the shared label but no eligibility, assignment, workflow, or Work inference. A C.2.1 claim about b-iam-crm is affirmative for <u-actor-label,d-iam-crm,r-actor,t-actor>.

Reliance on that claim remains conditional on the exact A.10 evidence-provenance relation and RelianceDisposition=pass for the named dashboard comparison. A hypothetical passing result would be an additional example premise, not a result recovered from the endpoint sketches. It would not authorize data processing, create a system-role assignment, or prove that a dashboard publication occurred. Reverse label reuse is another bounded-use claim even though the Bridge relation is symmetric.

An optional actual card may package the Bridge claim, this bounded-use claim, observed counterexamples, the A.10 path and disposition, currentness, and nearest non-use. Its EntityOfConcern is b-iam-crm; the card neither creates the relation nor performs the dashboard work.

If a later workflow isolates HumanVerifiedUser and VerifiedCustomer, refine both cells and test another Bridge. A stronger use claim over the broad cells cannot repair a false or unsuitable predicate.