The Advancement Common Data Model (ACDM™)
An open, vendor-neutral data model for nonprofit fundraising. A thin, neutral spine that maps to and from the major CRMs, so your data stays portable and comparable, with no lock-in.
What it covers
A thin spine, not a copy of any one CRM. The few things every shop needs to mean the same thing everywhere.
Constituent
People and organizations, including the households and relationships between them.
Gift Commitment
A promise to give: pledges, recurring agreements, memberships. Separate from the money itself.
Gift Transaction
The actual money movement that fulfills a commitment, with hard and soft credit.
Solicitation / Campaign
Appeals, campaigns, and the asks that drive giving.
Pipeline
Major-gift prospects and moves, modeled consistently across shops.
Who it's for
We're working with advancement shops now — and the model is built for every mission that raises money. Want to map your vertical? Join the beta and let's discuss the possibilities.
Advancement shops
Universities, schools, and foundations running portfolios, campaigns, and moves management.
Read how it maps → Modeled · seeking partnersFaith communities
Members, tithes, and pledge campaigns — with a dedicated congregation domain for life events.
Read how it maps → Modeled · seeking partnersHealthcare philanthropy
Grateful patient programs with consent and opt-outs as first-class, provable records.
Read how it maps → Modeled · seeking partnersHuman services
Programs, beneficiaries, grants, and impact modeled alongside the giving data.
Read how it maps →Maps to and from your CRM
Open crosswalks translate your existing system into the standard once, and keep you comparable to everyone else.
- Salesforce NPSP
- Salesforce Nonprofit Cloud
- Microsoft Nonprofit Common Data Model (NCDM)
- and more
Definitions are part of the standard
A metric isn't a name. It's a specification: numerator, denominator, time basis, population filter, edge cases, and segments. Pinned and versioned, so a number computed at one shop means the same thing at another. Anchored to sector standards like the Fundraising Effectiveness Project and CASE GRS.
Conformance, not capture
Anyone can build to the standard and claim conformance, including vendors you might choose instead of us. That a competitor can conform is the proof it belongs to no one.
The required entities and relationships: the minimum to be interoperable.
Core plus the common extensions most shops rely on.
The complete model, including the advanced and optional areas.
Explore it by your role
Nobody needs all 121 entities. Pick the hat you wear and see the handful the model keeps ready for your day — the same lenses beta members use in the full explorer.
“When a gift arrives, what do I record and where does it go?”
Gift
A single charitable transaction received by the institution. Maps to a CASE "gift" for counting. full_amount is the gross received; charitable_amount (full minus premium) is the deductible portion. WHO gets credit is on the `donors` (GiftDonor) records; WHERE the money goes is on the `allocations` (GiftAllocation) records.
47 fields in the beta explorer
Pledge
A commitment to give a total amount over time. The committed total (total_amount) counts toward CASE New Funds Committed. Each installment that satisfies the commitment is a real Gift whose `pledge` points back here (a "pledge payment"), counted once toward CASE Funds Received via Gift.full_amount — exactly as a sustainer charge is a Gift pointing at its RecurringGift. The Pledge carries the same donor credit (donors) and designation split (allocations) as a Gift, but that credit is COMMITTED credit: donor credit on a Pledge counts with New Funds Committed, donor credit on the installment Gifts counts with Funds Received, and the two are NEVER summed together (committed-vs-received discipline; docs/guides/business_rules.md §8). `scheduled_payments` is the EXPECTED / receivable forecast; the money actually received lives on the Gifts.
24 fields in the beta explorer
Recurring Gift
A sustainer / recurring-giving commitment: an open-ended schedule that charges a fixed recurring_amount on a frequency (monthly, ...) until paused, cancelled, or lapsed. Distinct from a Pledge (which commits a fixed TOTAL over a set number of installments); a sustainer has no fixed total. Each charge is recorded as a real Gift whose `recurring_gift` points back here, so the money counts as Funds Received once via the gifts module. Card-on-file is a TOKEN reference only (payment_token); ACDM never stores card or account numbers.
25 fields in the beta explorer
Gift Donor
How a party is associated with a gift or pledge, and the CREDIT they receive. One-or-more per Gift/Pledge (inlined). The `donor_role` says HOW they are tied to it: a primary / joint / group donor (who carries credit), or an in_memory_of / in_honor_of honoree (a non-giving party, no amounts). The four amounts are the distinct CREDIT types advancement tracks: legal (hard / receipted), soft (recognition credit to an influencer who did not legally give, e.g. a spouse or a foundation's principal), recognition (giving-society credit), and campaign (amount counted toward a campaign). Each party also carries their affiliation AS OF the gift date (donor_constituency) for source-based counting, and a per-party anonymity flag. Absorbs the former SoftCredit. For a TRIBUTE association (donor_role in_memory_of / in_honor_of) the party (constituent or honoree_name) is the honoree, and the notify_* fields capture who to inform (e.g. the family) and the message to convey; whether the notification was actually sent is downstream fulfillment, not stored here.
24 fields in the beta explorer
Gift Allocation
One line of a gift's / pledge's designation split: an amount directed to a designation. One-or-more per Gift/Pledge (inlined); together they sum to the charitable total. Replaces the single `designation` for split gifts; the flat `designation` remains the primary-designation Core convenience.
3 fields in the beta explorer
Gift Adjustment
A correction applied to a gift or pledge AFTER the fact: a refund, a reversal, a reclassification, or a pledge write-off. Adjustments are their OWN records and never mutate the original gift's amounts, so the audit trail and the original counting stay intact; CASE counting NETS adjustments downstream (a refund or reversal reduces counted Funds Received; a write-off reduces a pledge's outstanding commitment). Inlined on the Gift/Pledge it adjusts.
16 fields in the beta explorer
Designation
The specific purpose a gift supports (e.g. a named scholarship or the unrestricted annual fund).
19 fields in the beta explorer
Appeal
A specific solicitation effort within a campaign (e.g. "FY26 Year-End Email"). Gifts and pledges reference it via `appeal` (attribution). An appeal is delivered over a Channel, raises money for a Designation, and targets one or more Segments.
19 fields in the beta explorer
Matching Gift
An employer (or other) gift that matches a constituent's original gift.
15 fields in the beta explorer
“How is the campaign tracking, and where is the next big gift coming from?”
Campaign
A time-bound fundraising effort with a goal (e.g. a comprehensive campaign or a fiscal-year annual fund). Appeals roll up to a Campaign, and a Campaign may itself nest under a `parent_campaign` to model phases or sub-campaigns.
18 fields in the beta explorer
Appeal
A specific solicitation effort within a campaign (e.g. "FY26 Year-End Email"). Gifts and pledges reference it via `appeal` (attribution). An appeal is delivered over a Channel, raises money for a Designation, and targets one or more Segments.
19 fields in the beta explorer
Giving Season
A recurring annual-giving MOMENT realized for one cycle: a fiscal or calendar year-end push, a Giving Tuesday, or a day-of-giving. One record is one OCCURRENCE (e.g. "Giving Tuesday FY26"), bounded by start_date/end_date and tagged with a fiscal_year, while `season_type` groups occurrences of the same moment ACROSS years so reporting can line this year's Giving Tuesday up against last year's. A season is the cadence layer OVER the solicitation structure: the actual asks are a Campaign and its Appeals (campaigns.yaml), linked via `campaign`, and gifts attribute to those Appeals, not to the season, so the season never double-counts. `season_goal` holds the dollar target for the push; the actual raised is derived from the attributed gifts, never stored here.
20 fields in the beta explorer
Opportunity
A potential major gift worked through the cultivation pipeline — the prospect/relationship record. Carries the moves-management `stage`, an open/closed `opportunity_status`, a probability, expected and actual close dates, the managing `officer`, and what it is designated to fund. It holds NO dollar amounts: the ask lives on its Proposals (the ask lifecycle), and an opportunity's ask / expected / funded totals are DERIVED by rolling up the proposals and gifts attributed to it (via Proposal.opportunity) — forecasting is done through proposals. The contacts that advance it are Interactions (engagement.yaml) linked via their `opportunity`; the formal written asks are Proposals; the gift that closes it is attributed back via Gift.opportunity.
26 fields in the beta explorer
Proposal
A formal written ask within an Opportunity: the request put to a prospect for a specific purpose, with its own ask lifecycle. The ask moves through planned -> original -> adjusted ask amounts (each with its date), then a committed_amount when the donor commits, and a DERIVED received_amount rolled up from the gifts attributed to it (see Gift.proposal_attributions). This is where forecasting lives — an early forecast is a `draft` Proposal carrying a planned_ask_amount — and the entity the metrics.yaml `proposals` metric counts.
30 fields in the beta explorer
Gift
A single charitable transaction received by the institution. Maps to a CASE "gift" for counting. full_amount is the gross received; charitable_amount (full minus premium) is the deductible portion. WHO gets credit is on the `donors` (GiftDonor) records; WHERE the money goes is on the `allocations` (GiftAllocation) records.
47 fields in the beta explorer
Pledge
A commitment to give a total amount over time. The committed total (total_amount) counts toward CASE New Funds Committed. Each installment that satisfies the commitment is a real Gift whose `pledge` points back here (a "pledge payment"), counted once toward CASE Funds Received via Gift.full_amount — exactly as a sustainer charge is a Gift pointing at its RecurringGift. The Pledge carries the same donor credit (donors) and designation split (allocations) as a Gift, but that credit is COMMITTED credit: donor credit on a Pledge counts with New Funds Committed, donor credit on the installment Gifts counts with Funds Received, and the two are NEVER summed together (committed-vs-received discipline; docs/guides/business_rules.md §8). `scheduled_payments` is the EXPECTED / receivable forecast; the money actually received lives on the Gifts.
24 fields in the beta explorer
Designation
The specific purpose a gift supports (e.g. a named scholarship or the unrestricted annual fund).
19 fields in the beta explorer
Fund
An accounting fund that designations roll up to. Carries its nature via the shared `purpose_type` slot (current operations / endowment / property, plant & equipment / loan fund), a `restricted` flag, and an optional `parent_fund` for a fund hierarchy.
15 fields in the beta explorer
Score
A single typed score or rating for a constituent: capacity, affinity, inclination, lead, propensity (incl. ML), planned-giving likelihood, or priority. One shape for all of them. The value is expressed in whichever form fits the type: `score_amount` for a dollar capacity, `score_value` for a numeric score (e.g. 0-1 or 0-100), or `score_band` for a letter/label grade (A/B/C, High/Medium/Low); `score_scale` says how to read it. `score_source` says whether a person, a vendor, or a model produced it; for a model, the light provenance fields (model_name / model_version / confidence) make the prediction traceable, and `produced_by_model` optionally anchors them to an auditable ModelVersion record (ADR-0007). ACDM holds the score, NOT the model or its pipeline.
24 fields in the beta explorer
Performance Goal
A performance target set for an individual or a unit/team for a given period — e.g. "$2.5M raised in FY26", "150 visits", "30 proposals". The grain is subject x metric_type x period. Only the TARGET is stored; the actual achieved value is computed from gifts and interactions, not held here.
27 fields in the beta explorer
“Who has capacity and affinity, and where are they in the pipeline?”
Person
An individual person — alum, parent, friend, faculty, or staff.
64 fields in the beta explorer
Organization
A company, foundation, or other organization (e.g. a matching-gift employer or grant-making foundation). Beyond its name and high-level kind it carries an organizational profile: `organization_type` is the kind (corporation / foundation / government / ..., also the basis for organization-source reporting); `industry` is the finer industry bucket for a corporation; web, size, and financial signals (`website`, `founded_date`, `employee_count`, `annual_revenue`, `ticker_symbol`) support corporate-relations and capacity segmentation; and `parent_organization` is a self-reference for corporate family trees and matching-gift parent-company roll-ups. Tax / registry IDs (EIN, DUNS, ...) ride on `external_identifiers` (the MDM pattern), not bare slots.
43 fields in the beta explorer
Score
A single typed score or rating for a constituent: capacity, affinity, inclination, lead, propensity (incl. ML), planned-giving likelihood, or priority. One shape for all of them. The value is expressed in whichever form fits the type: `score_amount` for a dollar capacity, `score_value` for a numeric score (e.g. 0-1 or 0-100), or `score_band` for a letter/label grade (A/B/C, High/Medium/Low); `score_scale` says how to read it. `score_source` says whether a person, a vendor, or a model produced it; for a model, the light provenance fields (model_name / model_version / confidence) make the prediction traceable, and `produced_by_model` optionally anchors them to an auditable ModelVersion record (ADR-0007). ACDM holds the score, NOT the model or its pipeline.
24 fields in the beta explorer
Wealth Indicator
A discrete piece of wealth/capacity EVIDENCE for a constituent (real estate, securities, business ownership, known income, foundation affiliation, political giving, ...), usually from prospect research or a screening vendor. The descriptive facts behind a capacity Score; ACDM stores the evidence, the capacity conclusion is a Score (often source = vendor or model).
18 fields in the beta explorer
Affinity
A constituent's interest / affinity in some area: a sport, an academic discipline, a cause, an art form, an activity. Used for segmentation and matching (which prospects care about the rowing campaign, the marine-biology fund, climate). This is the STRUCTURED interests/affinities concept, a recognized advancement signal, and is deliberately distinct from the future generic Tag escape hatch (see ADR-0004's tag-vs-concept test): the specific area is free text (institution-specific, mapped via mappings/) while affinity_type groups it. Mixes in Provenanced so an INFERRED affinity (from a model or behavior) can carry confidence + as_of_date.
18 fields in the beta explorer
Opportunity
A potential major gift worked through the cultivation pipeline — the prospect/relationship record. Carries the moves-management `stage`, an open/closed `opportunity_status`, a probability, expected and actual close dates, the managing `officer`, and what it is designated to fund. It holds NO dollar amounts: the ask lives on its Proposals (the ask lifecycle), and an opportunity's ask / expected / funded totals are DERIVED by rolling up the proposals and gifts attributed to it (via Proposal.opportunity) — forecasting is done through proposals. The contacts that advance it are Interactions (engagement.yaml) linked via their `opportunity`; the formal written asks are Proposals; the gift that closes it is attributed back via Gift.opportunity.
26 fields in the beta explorer
Prospect History
One entry in a prospect's qualification lifecycle trail: a recorded change of `qualification_status` for a prospect (optionally under a given officer), with the change date and the reason. The light state-change history behind Assignment's CURRENT qualification_status, so the path identified → qualifying → qualified / disqualified / withdrawn — and WHY — can be reconstructed for analytics and the AI "what happened" view. ACDM stores the trail, not the pipeline-stage policy.
18 fields in the beta explorer
Assignment
The assignment of a prospect to a gift officer: the typed, time-bounded link that is the portfolio history. `assignment_type` says in what capacity (primary / secondary manager, solicitor, stewardship); the dates bound it (an open assignment_end_date means current); `assigned_by` records who made it. It also carries the prospect's qualification OUTCOME: `qualification_status` (identified → qualifying → qualified / disqualified / withdrawn) plus the reason a prospect was ruled out (`disqualified_reason`) or pulled from cultivation (`withdrawn_reason`). The state-change TRAIL behind the current status is ProspectHistory.
21 fields in the beta explorer
Interaction
A moves-management contact report / activity record: a completed contact / "move", or a PLANNED next step (interaction_status: planned, with a planned_date). When it advances a major-gift Opportunity it links via `opportunity`. Carries a direction, an outcome, and an optional next action with a due date. This is ACTIVITY, not engagement: an Interaction is NOT a CASE AEM engagement-count source (counting visit-type interactions as experiential would inflate the metric with staff outreach). Experiential engagement is recorded separately as EventAttendance — a campus visit is coded as Event(event_type: campus_visit) + EventAttendance(attended), not derived from this contact report. Mixes in MachineGenerated so an agent-logged or agent-summarized interaction is distinguishable from a human-authored one.
34 fields in the beta explorer
“What did they give, what did we promise, and how do we keep them close?”
Gift
A single charitable transaction received by the institution. Maps to a CASE "gift" for counting. full_amount is the gross received; charitable_amount (full minus premium) is the deductible portion. WHO gets credit is on the `donors` (GiftDonor) records; WHERE the money goes is on the `allocations` (GiftAllocation) records.
47 fields in the beta explorer
Gift Donor
How a party is associated with a gift or pledge, and the CREDIT they receive. One-or-more per Gift/Pledge (inlined). The `donor_role` says HOW they are tied to it: a primary / joint / group donor (who carries credit), or an in_memory_of / in_honor_of honoree (a non-giving party, no amounts). The four amounts are the distinct CREDIT types advancement tracks: legal (hard / receipted), soft (recognition credit to an influencer who did not legally give, e.g. a spouse or a foundation's principal), recognition (giving-society credit), and campaign (amount counted toward a campaign). Each party also carries their affiliation AS OF the gift date (donor_constituency) for source-based counting, and a per-party anonymity flag. Absorbs the former SoftCredit. For a TRIBUTE association (donor_role in_memory_of / in_honor_of) the party (constituent or honoree_name) is the honoree, and the notify_* fields capture who to inform (e.g. the family) and the message to convey; whether the notification was actually sent is downstream fulfillment, not stored here.
24 fields in the beta explorer
Gift Agreement
The legal agreement governing a major or endowed gift: what it establishes, its terms and donor restrictions, the reporting obligations back to the donor, and its signed / executed lifecycle. Links to the donor, the Designation it establishes (e.g. an endowed scholarship), and the Fund it is held in. The signed document itself is a Document (about this agreement); the reports it requires can be tracked as Documents / downstream.
23 fields in the beta explorer
Stewardship Consent
A recipient's recorded consent to be stewarded toward a donor — e.g. to be identified to the donor of their scholarship and to share a thank-you message, story, or photo. This is RELEASE / testimonial consent: the constituent grants permission for THEIR identity and words to be shared OUTWARD with a donor. It is deliberately separate from consent.yaml's CommunicationPreference (which governs whether WE may contact the constituent). Each grant carries a type, a status, an optional scholarship_award scope, and an expiry, so FERPA written consent is auditable and time-bounded. `full` subset.
19 fields in the beta explorer
Giving Society
A donor recognition society — the DEFINITION of a named recognition program (a President's Circle, a 1868-style lifetime society, a loyalty society, a Legacy/Heritage planned-giving society). Carries only its name and type; the giving thresholds that qualify a donor for it (and for each level) are institution POLICY recorded in mappings/, deliberately NOT stored here, since qualification is a derived roll-up (see module header).
14 fields in the beta explorer
Society Membership
A constituent's standing in a GivingSociety — the THIN, non-derivable core of society membership. Current qualification (does their cumulative/annual giving meet the threshold this year?) is derived downstream from gifts; what is stored here is what CANNOT be recomputed: the induction date, the conferred level, whether membership is honorary or a permanent lifetime conferral, the current stored standing, and the donor's honor-roll listing preference (`recognition_name` + `list_publicly` — the recognition analogue of Gift.anonymous). The member is the shared `constituent`.
21 fields in the beta explorer
Award
An honor or award a constituent RECEIVED from the institution — a distinguished-alumnus award, a service or volunteer award, a hall-of-fame induction, recognition of an honorary degree. The recipient is the shared `constituent`. Distinct from a GivingSociety / SocietyMembership (recognition CONFERRED BY GIVING) and from stewardship.ScholarshipAward (financial aid the constituent received as a BENEFICIARY): this is HONOR recognition OF the person, an alumni-engagement signal. It replaces having only free-text `VolunteerRole.recognition`. Slot names are honor-specific (conferred_date, award_standing, …) to stay clear of the scholarship `award_*` slots.
19 fields in the beta explorer
Scholarship Award
A scholarship or financial-aid award made TO a constituent (the recipient) from a financial-aid Fund/Designation — the beneficiary mirror of a Gift, and the join that closes the donor-stewardship loop. ACDM models the award only as that stewardship link (who received support from which fund), NOT as a financial-aid system of record: eligibility, need analysis, and disbursement accounting live in the SIS / financial-aid system. FERPA-sensitive, so the whole class is in the `full` subset; sharing a recipient's identity or message with the fund's donor additionally requires a StewardshipConsent.
20 fields in the beta explorer
Communication
A single outbound communication that actually went out — an email send, a direct-mail drop, a phone list. Ties the abstract appeal/segment/channel plan to a real event with a sent date. Mixes in MachineGenerated so an agent-drafted send is distinguishable from a human-authored one, with its model and review status.
26 fields in the beta explorer
Task
A standalone to-do / action item — distinct from `Interaction.next_action`, which folds the next step into a completed contact report. A Task is the first-class, assignable, status-tracked unit of PENDING work an officer (or an AI "what's next" agent) queues and clears. The ASSIGNEE is the Auditable `owner` (the actor currently responsible; reassignable). What the task concerns is the polymorphic `about` (a record id) + `about_type` (its kind: "Opportunity", "Gift", "Constituent", …), the same mechanism as Note / Alert; the optional typed `constituent` names the prospect directly for the common case. Working a task often PRODUCES an Interaction (the completed contact); ACDM does not link the two here — the Interaction stands on its own.
21 fields in the beta explorer
Contact Restriction
A NAMED, reasoned suppression on contacting a constituent — RE's central "Solicit Code" construct (e.g. "do not solicit", "no phone", "no contact until the estate settles"). Multivalued because a constituent can carry several at once. This is the layer ACDM's two simpler suppression mechanisms did not capture — a restriction WITH A REASON and an optional LIFT DATE, the auditable "why, and until when" both CRMs key on: - `Constituent.do_not_contact` is the BLANKET override (leave me alone); a consumer treats it as overriding everything below. - `CommunicationPreference` is per-channel/topic opt-in/opt-out consent. - `ContactRestriction` is the named, reasoned, time-bounded restriction. - reachability (a bounced email, returned mail) is DATA QUALITY in contacts.yaml, NOT permission. The optional `channel` scopes a restriction to one medium (do_not_contact + direct_mail = "do not mail"); absent means it applies broadly. Whether a given restriction blocks a particular send is policy applied downstream — ACDM stores the restriction, not the rule.
19 fields in the beta explorer
“Where did this data come from, who can we contact, and is it governed?”
Person
An individual person — alum, parent, friend, faculty, or staff.
64 fields in the beta explorer
Organization
A company, foundation, or other organization (e.g. a matching-gift employer or grant-making foundation). Beyond its name and high-level kind it carries an organizational profile: `organization_type` is the kind (corporation / foundation / government / ..., also the basis for organization-source reporting); `industry` is the finer industry bucket for a corporation; web, size, and financial signals (`website`, `founded_date`, `employee_count`, `annual_revenue`, `ticker_symbol`) support corporate-relations and capacity segmentation; and `parent_organization` is a self-reference for corporate family trees and matching-gift parent-company roll-ups. Tax / registry IDs (EIN, DUNS, ...) ride on `external_identifiers` (the MDM pattern), not bare slots.
43 fields in the beta explorer
Gift
A single charitable transaction received by the institution. Maps to a CASE "gift" for counting. full_amount is the gross received; charitable_amount (full minus premium) is the deductible portion. WHO gets credit is on the `donors` (GiftDonor) records; WHERE the money goes is on the `allocations` (GiftAllocation) records.
47 fields in the beta explorer
Score
A single typed score or rating for a constituent: capacity, affinity, inclination, lead, propensity (incl. ML), planned-giving likelihood, or priority. One shape for all of them. The value is expressed in whichever form fits the type: `score_amount` for a dollar capacity, `score_value` for a numeric score (e.g. 0-1 or 0-100), or `score_band` for a letter/label grade (A/B/C, High/Medium/Low); `score_scale` says how to read it. `score_source` says whether a person, a vendor, or a model produced it; for a model, the light provenance fields (model_name / model_version / confidence) make the prediction traceable, and `produced_by_model` optionally anchors them to an auditable ModelVersion record (ADR-0007). ACDM holds the score, NOT the model or its pipeline.
24 fields in the beta explorer
Wealth Indicator
A discrete piece of wealth/capacity EVIDENCE for a constituent (real estate, securities, business ownership, known income, foundation affiliation, political giving, ...), usually from prospect research or a screening vendor. The descriptive facts behind a capacity Score; ACDM stores the evidence, the capacity conclusion is a Score (often source = vendor or model).
18 fields in the beta explorer
Communication Preference
A consent state for a given channel, optionally scoped to a topic (e.g. opt out of email solicitation but opt in to the email newsletter). The subject is normally a `constituent`; it MAY instead (or additionally) be a `household`, so a channel/topic preference can be recorded at the giving-unit grain. The most recent `effective_date` for a (subject, channel, topic) wins.
19 fields in the beta explorer
Contact Restriction
A NAMED, reasoned suppression on contacting a constituent — RE's central "Solicit Code" construct (e.g. "do not solicit", "no phone", "no contact until the estate settles"). Multivalued because a constituent can carry several at once. This is the layer ACDM's two simpler suppression mechanisms did not capture — a restriction WITH A REASON and an optional LIFT DATE, the auditable "why, and until when" both CRMs key on: - `Constituent.do_not_contact` is the BLANKET override (leave me alone); a consumer treats it as overriding everything below. - `CommunicationPreference` is per-channel/topic opt-in/opt-out consent. - `ContactRestriction` is the named, reasoned, time-bounded restriction. - reachability (a bounced email, returned mail) is DATA QUALITY in contacts.yaml, NOT permission. The optional `channel` scopes a restriction to one medium (do_not_contact + direct_mail = "do not mail"); absent means it applies broadly. Whether a given restriction blocks a particular send is policy applied downstream — ACDM stores the restriction, not the rule.
19 fields in the beta explorer
Demographics
Sensitive DEI / equity demographics for a person, kept in a SEPARATE, governance-gated sub-record (one per Person, inlined) so it is easy to restrict or redact and does not scatter sensitive fields across Person. ACDM provides the PLACES; it does NOT prescribe value lists (ethnicity is free text, mapped via mappings/) because the categories are institution- and country-specific. GOVERNANCE: collect only with consent and a lawful basis, gate access, never require. `full` subset throughout.
17 fields in the beta explorer
Designation
The specific purpose a gift supports (e.g. a named scholarship or the unrestricted annual fund).
19 fields in the beta explorer
Fund
An accounting fund that designations roll up to. Carries its nature via the shared `purpose_type` slot (current operations / endowment / property, plant & equipment / loan fund), a `restricted` flag, and an optional `parent_fund` for a fund hierarchy.
15 fields in the beta explorer
Follow a gift
Watch a real $5,000 gift travel through the model — donor, credit, designation, appeal, and a later refund — one step at a time.
Join the beta to take the tour → In the betaMap your CRM
See how the everyday words you already use — constituents, soft credits, appeals, actions — line up with the model, crosswalked for NPSP, Nonprofit Cloud, and Microsoft NCDM.
Join the beta to see your mapping →The full model, entity by entity
Every entity in the standard, in plain English. The field-level reference — types, PII flags, and CRM crosswalks — lives in the beta explorer.
121 entities · 2,396 fields · crosswalks for NPSP, Nonprofit Cloud & Microsoft NCDM
AI & automation 2 entities
Signals and structures that make the data safe for AI and automation.
AI & automation 2 entities
Signals and structures that make the data safe for AI and automation.
Agent
An autonomous AI agent that acts on advancement data — drafting and sending outreach, advancing an ask, routing a prospect, writing back a score. A concrete Actor (like User), so it is a valid value for created_by / modified_by / owner: an automated edit attributes to a NAMED agent rather than an anonymous service account. Records WHAT it runs (runs_model / model_name / model_version), HOW independently it acts (autonomy_level), and WHAT it is permitted to do (tool_scope). An agent usually runs AS a User service account (service_account); the Agent is its own first-class record. ACDM holds the agent's identity and authority, NOT its internals (prompts, reasoning, tool-call logs).
19 fields in the beta explorer
Agent Action
A single action an agent took or proposed — the agentic analog of what Score is for a fact. Records the agent, the action type, what it acted on (acted_on for the common person case; target_record_id + target_class for anything else), what triggered it (triggered_by_score), the model behind it (produced_by_model), its decision status, and the human who reviewed it (reviewed_by — the human-in-the-loop seam). `Provenanced.confidence` carries how sure the agent was. ACDM does NOT enforce that reviewed_by is populated or tie decision_status to autonomy_level: oversight enforcement is an application concern; the standard carries the structure for interoperability and audit.
25 fields in the beta explorer
Annual fund 1 entity
Annual giving programs and the yearly rhythm of asks.
Annual fund 1 entity
Annual giving programs and the yearly rhythm of asks.
Giving Season
A recurring annual-giving MOMENT realized for one cycle: a fiscal or calendar year-end push, a Giving Tuesday, or a day-of-giving. One record is one OCCURRENCE (e.g. "Giving Tuesday FY26"), bounded by start_date/end_date and tagged with a fiscal_year, while `season_type` groups occurrences of the same moment ACROSS years so reporting can line this year's Giving Tuesday up against last year's. A season is the cadence layer OVER the solicitation structure: the actual asks are a Campaign and its Appeals (campaigns.yaml), linked via `campaign`, and gifts attribute to those Appeals, not to the season, so the season never double-counts. `season_goal` holds the dollar target for the push; the actual raised is derived from the attributed gifts, never stored here.
20 fields in the beta explorer
Beneficiaries 3 entities
The people and communities your programs serve.
Beneficiaries 3 entities
The people and communities your programs serve.
Eligibility Determination
The RECORD of a decision that a recipient qualifies (or not) for a program — NOT an eligibility rules engine. ACDM stores the determination (who, which program, the outcome, when); the rules that produced it are app policy (ADR-0012).
16 fields in the beta explorer
Referral
The RECORD of how a service recipient entered — where the referral came from, when, and to what program. Not a referral workflow / routing engine (ADR-0012), just the fact of the referral.
16 fields in the beta explorer
Service Recipient
A person the organization serves (a client / participant / beneficiary), modeled DISTINCT from Constituent so client data stays segregable and PII-gated, anonymous/walk-in clients are representable, and a person who is both a donor and a client is not conflated. The optional `person` link is the bridge when the same human is both. Sensitive demographics live on the linked Person's governance-gated Demographics sub-record (or are omitted for an anonymous recipient), NOT duplicated here.
19 fields in the beta explorer
Campaigns & appeals 4 entities
Campaigns, appeals, and the asks that drive giving.
Campaigns & appeals 4 entities
Campaigns, appeals, and the asks that drive giving.
Appeal
A specific solicitation effort within a campaign (e.g. "FY26 Year-End Email"). Gifts and pledges reference it via `appeal` (attribution). An appeal is delivered over a Channel, raises money for a Designation, and targets one or more Segments.
19 fields in the beta explorer
Appeal Package
A specific package or version (e.g. green envelope vs. white envelope, or email copy variation) used within an Appeal for A/B testing or marketing optimization.
16 fields in the beta explorer
Campaign
A time-bound fundraising effort with a goal (e.g. a comprehensive campaign or a fiscal-year annual fund). Appeals roll up to a Campaign, and a Campaign may itself nest under a `parent_campaign` to model phases or sub-campaigns.
18 fields in the beta explorer
Segment
An audience slice targeted by an appeal (e.g. "LYBUNT alumni", "Major-gift prospects in the Northeast"). The selection rules are institution-specific; ACDM standardizes the structure (`criteria` as free text), not the rules. A model-built segment may anchor to the ModelVersion that produced it via `produced_by_model` (ADR-0007).
16 fields in the beta explorer
Communications 2 entities
Messages sent and received, across every channel.
Communications 2 entities
Messages sent and received, across every channel.
Communication
A single outbound communication that actually went out — an email send, a direct-mail drop, a phone list. Ties the abstract appeal/segment/channel plan to a real event with a sent date. Mixes in MachineGenerated so an agent-drafted send is distinguishable from a human-authored one, with its model and review status.
26 fields in the beta explorer
Response
A constituent's recorded reaction to a communication — a delivery/engagement event (delivered, opened, clicked, unsubscribed) or an explicit response (replied, gave). When the response is a gift, `resulting_gift` links it.
17 fields in the beta explorer
Congregations 8 entities
Faith communities: congregations, members, and their life events.
Congregations 8 entities
Faith communities: congregations, members, and their life events.
Attendance Count
An AGGREGATE headcount for an occasion — the aggregate sibling of the per-person ServiceAttendance (Decision 7). Churches headcount worship rather than name-scan every adult, and the denominational annual-report frame this vertical anchors to reports "average weekly worship attendance" — an aggregate. ACDM stores no aggregate ACTUAL elsewhere (metrics.yaml holds fundraiser TARGETS only), so without this class the headline attendance metric is unanswerable for the common case. The report line derives from AttendanceCount when present, else from counting distinct ServiceAttendance rows. Carries the total plus an optional adult / youth / child split and how the count was taken (`count_method`).
20 fields in the beta explorer
Faith Milestone
A sacrament / ordinance / life-event record — baptism, confirmation, profession of faith, first communion, marriage performed, child dedication, funeral, membership received / transferred. The entity name stays NEUTRAL because "sacrament" vs "ordinance" is itself a Christian intra-tradition split; the Christian-oriented framing lives in `milestone_type`, so both readings sit on one record (Decision 2). This is the church's "record of record" — fit to issue a certificate from — carrying the person, the date, the officiant, the congregation, the participants (sponsors / godparents / witnesses, by link OR by name), and a `certificate_number`. ACDM standardizes the structure; it does NOT enforce sacramental/membership sequencing rules (e.g. "baptism precedes membership") — that is the app's policy.
20 fields in the beta explorer
Milestone Participant
One participant in a FaithMilestone other than the principal `person` — a baptism sponsor / godparent, a marriage witness, a presenter, or a parent at a child dedication. A small inlined value (like MonetaryAmount), NOT an entity in its own right; FaithMilestone carries many via `participants`. Either a `person` link (a known constituent) OR a free-text `participant_name` is given, so a godparent or witness who is not in the system can still be recorded — the common case for the certificate (Decision 9). At least one of `person` / `participant_name` MUST be present.
3 fields in the beta explorer
Ministry
An ongoing internal group / team / class of the congregation — a small group, Bible study, ministry/serving team, choir, committee, or prayer group. The congregation analog of a program container, mirroring the MembershipProgram / Membership idiom: a Ministry holds the people on its roster via MinistryMembership (Decision 3). Self-referential via `parent_ministry` so groups nest (a sub-group under a ministry), mirroring parent_unit / parent_fund. In the congregation vertical, prefer `Ministry` for ALL internal groups including committees; reserve VolunteerGroup / MembershipProgram for advancement use (the Decision 10 concept boundary).
17 fields in the beta explorer
Ministry Membership
A person's place on a specific Ministry's roster, with a role — the per-person association mirroring Membership (engagement.yaml): the group plus a role and validity dates (Decision 3). The first step of the serving chain MinistryMembership (on the team) → ServingAssignment (rostered for a date) → VolunteerTimeEntry (served N hours). Use this for group-roster membership; use Affiliation for a person's STANDING relationship to the congregation (member / regular attender / visitor) — the Decision 10 boundary.
17 fields in the beta explorer
Minor Safety Profile
Standing child-safety facts for a minor in children's ministry (Decision 8): allergies, a brief operational note, special needs, who may collect the child, and any custody / pickup limitation. Where ServiceAttendance.checked_in_by + security_code match a pickup AT THE DOOR for one visit, these are the STANDING facts an app validates a check-out against — held once on the child, not copied onto every attendance row. `medical_notes` is deliberately a brief OPERATIONAL note ("what serving volunteers must know"), NOT a clinical record (HIPAA clinical data stays the non_giving.yaml health vertical). This is markedly higher-sensitivity than typical advancement data: keep it restricted-access with data-minimization (congregation profile governance). Photo / likeness permission reuses the existing media-release consent in stewardship.yaml rather than being duplicated here.
17 fields in the beta explorer
Service Attendance
A PER-PERSON record of recurring worship / class / group attendance and secure child check-in. Distinct from EventAttendance, which models attendance at a named Event with RSVP / quid-pro-quo semantics: recurring worship has no Event row per Sunday, and child check-in (the drop-off guardian + a pickup security code) is a safety concept EventAttendance does not carry (Decision 4). Person-grain by default, with an optional `household` link for a family check-in. Aggregate worship headcounts use AttendanceCount instead. At least one of `person` / `household` MUST be present. Child check-in / minor-presence data here is HIGHER-SENSITIVITY than typical advancement data and is restricted-access in the congregation profile governance.
21 fields in the beta explorer
Serving Assignment
A forward SERVING-ROSTER record: a person is rostered to serve in a ministry/ role on a service date, through a scheduled → confirmed → served lifecycle (Decision 11). The missing MIDDLE link of the serving chain — between MinistryMembership (on the team) and VolunteerTimeEntry (hours already served); `status: served` closes the loop to the existing time-entry record. ACDM holds the assignment RECORD, NOT the auto-scheduler — availability / blackout solving, conflict detection, shift-swap requests, and reminders stay an explicit Non-Goal. Eligibility to serve (background-check clearance) is also deliberately NOT modeled; that high-sensitivity data lives in the church's safe-ministry / screening system, and an implementation gates serving on it downstream.
20 fields in the beta explorer
Consent & preferences 2 entities
What you may send, to whom, and the preferences behind it.
Consent & preferences 2 entities
What you may send, to whom, and the preferences behind it.
Communication Preference
A consent state for a given channel, optionally scoped to a topic (e.g. opt out of email solicitation but opt in to the email newsletter). The subject is normally a `constituent`; it MAY instead (or additionally) be a `household`, so a channel/topic preference can be recorded at the giving-unit grain. The most recent `effective_date` for a (subject, channel, topic) wins.
19 fields in the beta explorer
Contact Restriction
A NAMED, reasoned suppression on contacting a constituent — RE's central "Solicit Code" construct (e.g. "do not solicit", "no phone", "no contact until the estate settles"). Multivalued because a constituent can carry several at once. This is the layer ACDM's two simpler suppression mechanisms did not capture — a restriction WITH A REASON and an optional LIFT DATE, the auditable "why, and until when" both CRMs key on: - `Constituent.do_not_contact` is the BLANKET override (leave me alone); a consumer treats it as overriding everything below. - `CommunicationPreference` is per-channel/topic opt-in/opt-out consent. - `ContactRestriction` is the named, reasoned, time-bounded restriction. - reachability (a bounced email, returned mail) is DATA QUALITY in contacts.yaml, NOT permission. The optional `channel` scopes a restriction to one medium (do_not_contact + direct_mail = "do not mail"); absent means it applies broadly. Whether a given restriction blocks a particular send is policy applied downstream — ACDM stores the restriction, not the rule.
19 fields in the beta explorer
Contact details 4 entities
Addresses, emails, phones, and how to reach people the right way.
Contact details 4 entities
Addresses, emails, phones, and how to reach people the right way.
Address Association
The link between a party (Person, Organization, or Household) and a shared Address: how that party uses that place. It carries the per-party facts an Address deliberately does not (the address_type, whether it is their primary, the validity span, a seasonal/"snowbird" range, and deliverability status) and points at the Address by id via `address`, so many parties can share one physical location with no duplication. A pure inlined child of its owner (like FormattedName): the owner is implied by where it is inlined, so there is no back-reference, which lets a Household hold one too.
22 fields in the beta explorer
Email Address
One of a constituent's email addresses, with a type (personal / work / …), a primary flag, an optional validity span, and a reachability status (active / bounced / invalid). Personal rather than shared, so it is inlined on the constituent (not a shared entity like Address). Whether we MAY email is consent.yaml, not here.
20 fields in the beta explorer
Phone Number
One of a constituent's phone numbers, with a type (mobile / home / work / fax), a primary flag, an optional extension and validity span, and a reachability status (active / disconnected / wrong_number). Personal rather than shared, so it is inlined on the constituent. Whether we MAY call is consent.yaml, not here.
21 fields in the beta explorer
Social Media Account
One of a constituent's social-media / online-presence accounts: a platform (LinkedIn / Facebook / X / …), the handle or profile URL, a primary flag, an optional validity span, and an optional reachability status (active / inactive). Personal rather than shared, so it is inlined on the constituent, exactly like EmailAddress / PhoneNumber. Reachability is a data-quality fact, NOT permission: whether we MAY engage on a channel stays in consent.yaml. Adopts the Effective mixin (the generic valid_from / valid_to / is_current valid-time hook) as the model's demonstrative SCD-2 adopter, in addition to the legacy contact_valid_from/to it shares with the other contact points.
23 fields in the beta explorer
Designations & funds 4 entities
Where gifts are directed: funds, designations, and restrictions.
Designations & funds 4 entities
Where gifts are directed: funds, designations, and restrictions.
Designation
The specific purpose a gift supports (e.g. a named scholarship or the unrestricted annual fund).
19 fields in the beta explorer
Designation Link
A directed, typed link between TWO designations that is NOT an accounting roll-up (use `Fund.parent_fund` for roll-up): the endowed corpus that FUNDS a current-use spending designation, the sibling scholarships a single bequest created grouped under a PARENT memorial designation, or a designation that SUPERSEDES a retired one. Mirrors the constituent↔constituent Relationship class — `from_designation` → `to_designation` + a typed `designation_link_type` + a `reciprocal_link` pairing the inverse record (A funds B ↔ B funded_by A) — so these networks live in DATA (not a fund manager's head or a note), survive migration, and can ground an AI asked "what funds this scholarship?". Distinct from DesignationRelationship, which links a designation to a PERSON (Constituent); this links designation to designation. See ADR-0006.
16 fields in the beta explorer
Designation Relationship
A person's role with respect to a designation / fund: a steward or fund manager who oversees it, a contact, an advisor, or the honoree the fund is named for / memorializes. Links a Designation to a Constituent with a typed `designation_role` and an optional timeframe, so the people behind a fund are recorded in DATA (not buried in notes) and stewardship / fund management can be driven. A standalone record referencing the Designation by id (mirroring Assignment), because the same person can relate to several funds. A steward who is internal staff is modeled as the Constituent record for that person (e.g. a faculty principal with a faculty affiliation), per the constituent range; the assigned gift OFFICER's stewardship sits on portfolios.Assignment.
17 fields in the beta explorer
Fund
An accounting fund that designations roll up to. Carries its nature via the shared `purpose_type` slot (current operations / endowment / property, plant & equipment / loan fund), a `restricted` flag, and an optional `parent_fund` for a fund hierarchy.
15 fields in the beta explorer
Digital engagement 2 entities
Web, email, and online behavior signals.
Digital engagement 2 entities
Web, email, and online behavior signals.
Digital Engagement Event
One digital engagement ACTION, one row — the raw, immutable, replayable landing grain of behavioral data (a page view, an email open/click, a video play, a form start/submit, an ad click, a social engagement, an app screen view, a download, a search). This is WAREHOUSE grain, not interchange (ADR-0014): append-only and high-volume, it is fenced out of every depth profile and surfaced only on the MLOps axis. Distinct from `engagement.Interaction` and `communications.Response`, and deliberately so. An Interaction is a 1:1 gift-officer contact report (a "move") AUTHORED about a single constituent; a Response is a reaction to a specific institutional SEND. A DigitalEngagementEvent is neither: it is machine-emitted by a tag manager / CDP / ESP, it is ANONYMOUS-CAPABLE (it may carry only an opaque `visitor_key` with no `constituent`, for pre-identification web/social traffic stitched to a constituent later), and it is SEND-INDEPENDENT (it requires no communication — organic and send-less actions are valid; `source_communication` is populated only when the action is attributable to a send). `event_timestamp` is the single hard requirement beyond `id` — it is the grain anchor. It mixes in Auditable (it lands FROM a source system) and MachineGenerated (it is emitted by automation, not authored), but NOT Provenanced: a raw event is an append-only record of something that happened, never a volatile as-of value.
28 fields in the beta explorer
Engagement Profile
A per-constituent DERIVED engagement feature record — the read-shape a model or a segmentation rule scores against (recency, frequency, breadth, the date of last engagement, an optional rolled-up score, topic affinities, and the feature window the features were computed over). The derived counterpart to the raw DigitalEngagementEvent landing grain: a vault rolls up many events into one profile per constituent. Like prospect_research.Score, this standardizes the feature's SHAPE and its PROVENANCE ONLY — never the roll-up COMPUTATION. ACDM prescribes no normative formula or threshold for `engagement_score`; any populated score is accompanied by a free-text/URI `score_method` describing how it was derived (AGENTS.md convention #6 — engagement scores are deliberately not baked in). It mixes in Provenanced, so every profile carries `as_of_date` (when the features were true / computed as of) and `confidence` — a feature row is a volatile derived as-of fact. `constituent` is REQUIRED: a profile is always ABOUT a resolved constituent (unlike the anonymous-capable event).
21 fields in the beta explorer
Engagement 12 entities
Events, interactions, and the touchpoints that build relationships.
Engagement 12 entities
Events, interactions, and the touchpoints that build relationships.
Event
An advancement event or gathering constituents can attend — reunion, homecoming, gala, lecture, regional club night, webinar, etc. This is the thing attended; a constituent's participation in it is an EventAttendance.
26 fields in the beta explorer
Event Attendance
A constituent's participation in an Event — the countable unit for AEM EXPERIENTIAL engagement. `attendance_status = attended` is the "engaged" signal (a registration that never showed is not). Standalone: it references the event and the constituent (mirroring communications Response rather than being inlined under Event) so it scales to large attendee lists. It also carries the event REVENUE the constituent paid (a ticket, table, or sponsorship — gated by attendee_role) with the SAME quid-pro-quo split as Membership dues: ticket_amount is the gross paid, benefit_value the FMV of benefits received, and qualifying_gift the Gift carrying the charitable remainder (so it counts via gifts.yaml). The deductible split itself is downstream tax/institution policy (the §6115 quid-pro-quo disclosure rule).
23 fields in the beta explorer
Event Ticket Package
A ticketing or registration package offered for an Event (e.g. Early Bird, VIP table, Gala ticket).
17 fields in the beta explorer
Fundraising Effort
A volunteer-run or peer-to-peer fundraising effort: a class / reunion gift drive, a crowdfunding project, a giving-day team. Carries an `organizer` (the volunteer or constituent running it), an optional staff `coordinator`, what it raises FOR (`designation`) and rolls up to (`campaign`), an `effort_goal`, a date window, and a lifecycle `effort_status`. The volunteer solicitor's IMPACT is NOT modeled with new credit logic: gifts they bring in are soft-credited to the organizer via a GiftDonor with a soft_amount and donor_role solicitor (gifts.yaml), and a solicitor-to-prospect link, when tracked, reuses Assignment (portfolios.yaml). Like GivingSeason, the effort is a context / grouping layer: gifts attribute through their Appeal plus the soft credit, not via a direct effort foreign key, so the effort never double-counts.
22 fields in the beta explorer
Interaction
A moves-management contact report / activity record: a completed contact / "move", or a PLANNED next step (interaction_status: planned, with a planned_date). When it advances a major-gift Opportunity it links via `opportunity`. Carries a direction, an outcome, and an optional next action with a due date. This is ACTIVITY, not engagement: an Interaction is NOT a CASE AEM engagement-count source (counting visit-type interactions as experiential would inflate the metric with staff outreach). Experiential engagement is recorded separately as EventAttendance — a campus visit is coded as Event(event_type: campus_visit) + EventAttendance(attended), not derived from this contact report. Mixes in MachineGenerated so an agent-logged or agent-summarized interaction is distinguishable from a human-authored one.
34 fields in the beta explorer
Membership
A constituent's enrollment in a MembershipProgram — the durable membership record (mirrors VolunteerRole / EventAttendance). It carries the level/tier, a member_type (annual / life / honorary / automatic), a status lifecycle, the current term (year-only or full dates), and the dues. Membership dues are often QUID PRO QUO — part fair-market benefit, part gift — so `dues_amount` is NOT a gift amount: the charitable portion flows through a real Gift, linked via `qualifying_gift` (so it counts via gifts.yaml), and `benefit_value` records the FMV of benefits. The deductible split itself (e.g. the post-2018 rule that amounts paid for the right to buy athletic seating are non-deductible) is tax/institution POLICY applied downstream, not modeled here. The free/automatic "all alumni are members" model is just `member_type = automatic` with no dues.
25 fields in the beta explorer
Membership Program
A membership program a constituent can belong to — the alumni association, an athletics booster club, a museum/arts "friends" program, a library guild, or a professional/affinity network. This is the OFFERING; a constituent's enrollment in it is a Membership. Made first-class and owned by an OrganizationalUnit precisely so athletics, the arts, the library, etc. can each define their own programs and tiers IN DATA — not by changing the schema — rather than membership being hard-coded as "alumni only". `gift_funded` flags programs whose dues are (wholly or partly) a charitable gift.
17 fields in the beta explorer
Student Activity Involvement
A constituent's historic involvement or participation in student activities (e.g., crew team, greek life, student government).
17 fields in the beta explorer
Volunteer Group
A standing volunteer body: a board of trustees, advisory council, committee, alumni chapter/club, reunion class committee, or event host committee. People serve on it via VolunteerRole. A board is NOT a role_type value — it is a group with seats, terms, and officers.
20 fields in the beta explorer
Volunteer Role
A constituent's standing volunteer involvement — a seat on a VolunteerGroup or a free-standing role (class agent, mentor, ambassador). The durable "involvement" record: it carries a STATUS and a (possibly year-only) timeframe, plus optional term, office, skills, screening, and recognition. It does NOT carry hours — those are its VolunteerTimeEntry children.
35 fields in the beta explorer
Volunteer Solicitation
A volunteer moves-management assignment: a volunteer (in a committee seat / VolunteerRole) is soliciting a specific prospect, the link ACDM has no way to record today. A thin NEW class rather than a widening of Assignment (portfolios.yaml): Assignment.officer is `range: GiftOfficer` AND required, but a volunteer solicitor is a Constituent, not staff — relaxing a required slot on a standard class to fit volunteers would destabilize a class portfolios and downstream consumers depend on, to save one small class (design D7). It REUSES rather than reinvents: `qualification_status` (QualificationStatus, portfolios.yaml) for the prospect's qualification outcome, and the established soft-credit IMPACT path (a GiftDonor with a soft_amount and donor_role solicitor, gifts.yaml) for the volunteer's dollars — no new credit logic. Roll-up to the committee is `volunteer_role -> volunteer_group`.
19 fields in the beta explorer
Volunteer Time Entry
A discrete record of time served — the unit you SUM to report hours. Attaches to a VolunteerRole when one exists, but can stand alone for a one-off event volunteer. Either a precise service_date OR a coarse service_year may be given (precision follows the source system).
20 fields in the beta explorer
Foundations 11 entities
The shared building blocks every other part of the model stands on.
Foundations 11 entities
The shared building blocks every other part of the model stands on.
Address
A physical postal location, modeled as a FIRST-CLASS, shareable entity so that several constituents at the same place (spouses, a family, an employer and its employees) reference ONE Address record by id rather than each duplicating the street/city/postal fields. The per-party facts about a place (what TYPE it is for them, whether it is their primary, when they lived there) are NOT stored here; they live on AddressAssociation (contacts.yaml), because the same building can be one person's home and another's business. This carries only the location itself plus optional geocode and a standardization flag.
20 fields in the beta explorer
Alert
A flag / annotation that should surface PROMINENTLY when a record is opened — "VIP, clear contact with the President's office", "legal hold", "bankruptcy", "media-sensitive". Attachable to ANY entity via the polymorphic `about` (the record's id) + `about_type` (its entity kind), the same pattern as Note / Document, so an alert can sit on a Constituent, a Gift, a Grant, etc. without modifying each class. An Alert is the human-facing "read me first" banner; it SURFACES a fact for staff and is NOT the system of record for it — the deceased flag still lives on Person.deceased, a named/reasoned suppression on ContactRestriction + consent, a rating on Score. Distinct from those (do not branch logic on an Alert), and from a Note (passive context, not a pop-up).
19 fields in the beta explorer
Document
A pointer to a stored document / file ABOUT some record (a signed gift agreement, a proposal PDF, correspondence, an image), attachable to ANY entity via the polymorphic `about` + `about_type`. ACDM stores the METADATA and a URI / locator, not the file bytes.
17 fields in the beta explorer
Extension
One governed, namespaced, STRUCTURED extension on a record — a single typed fact about a concept ACDM does not (yet) model. A small inlined value (like Tag / SourceValue / ExternalIdentifier), NOT an entity in its own right; a record carries many via the `extensions` list (the Extensible mixin, ADR-0010). NOT AN ATTRIBUTE BAG (the ADR-0001 distinction). The rejected bag was ungoverned: arbitrary keys, no definition, no owner, consumers forced to join-and-guess. An Extension is the disciplined form of the same idea, the shape FHIR settled on for the same problem: - `extension_uri` is a RESOLVABLE definition URI in the EXTENDING institution's OWN namespace (its ROR id / DNS domain — the ADR-0008 institution_namespace anchor), NEVER the `acdm:` core namespace. It resolves to a definition (name, datatype, cardinality, description), so the value is self-describing and two institutions cannot collide. - exactly ONE typed `value_*` is populated (the `exactly_one_of` below), so the value is validatable rather than an opaque string. NON-CANONICAL — shares the do-not-branch fence with SourceValue / Tag, plus a must-ignore rule (VERSIONING.md): cross-institution reporting and Core/standard interop MUST IGNORE an extension whose `extension_uri` they do not recognize; only the OWNING namespace may branch on its own extension. So an extension can never silently break a benchmark count. Two further rules: (1) do NOT use an extension to encode a concept ACDM already models — the same shadowing test as Tag (an Affiliation, a Score, a consent fact belongs in its modeled slot, not an extension); extensions are for GENUINELY NEW structure, the rung above tags. (2) An extension that many institutions add the same way is a PROMOTION candidate: the Steering Committee folds a common extension into the core schema (additive MINOR), which is what converts fork pressure into input to the standard. Complex / nested extension values are deliberately out of scope for now (model a new concept as several scalar extensions under one namespace, or petition for promotion); only scalar typed values are supported.
8 fields in the beta explorer
External Identifier
One of a record's identifiers in an external system. The same constituent is known by different keys in the CRM, the SIS, the email platform, wealth screening, finance, and so on; each is an ExternalIdentifier. A small inlined value (like MonetaryAmount), not an entity in its own right. The primary one is also denormalized onto Auditable.source_system / source_record_id for Core convenience.
4 fields in the beta explorer
Geographic Region
A named geographic (or program) region used for segmentation and gift-officer TERRITORY — a metro area, a multi-state grouping ("Northeast"), a country, or a regional-club catchment. Self-referential via `parent_region` so regions nest (a metro within a state within a country), mirroring parent_unit / parent_fund. An Address points at the region it falls in (`Address.geographic_region`); a gift officer's coverage points at it (`GiftOfficer.geographic_region`), so officer territories and regional-club segmentation resolve in DATA rather than via a free-text label. Defined here in the foundation (alongside Address) so both contacts and portfolios can reference it without an import cycle.
14 fields in the beta explorer
Identity Assertion
A NON-AUTHORITATIVE assertion that two global identities (`global_id` values) denote the same real-world entity — or are explicitly distinct — ACROSS the institutional boundary. The cross-institution counterpart to the within-institution Reconcilable merge: where `merged_from` / `is_golden` record a merge INSIDE one shop, an IdentityAssertion records a MATCH BETWEEN two shops WITHOUT merging, deleting, or taking ownership of either record — each institution keeps its sovereign record. Mixes in Provenanced so every assertion carries `as_of_date` + `confidence`: it is EVIDENCE, not truth, MUST NOT trigger a merge, and consumers MAY filter by confidence. This is what lets sovereign, per-institution data federate for commons benchmarking. See ADR-0008.
18 fields in the beta explorer
Model Version
A specific trained version of a predictive or generative model, recorded so a Score, Segment, or AgentAction can be traced to ONE auditable model record (which model, which version, who owns it, whether it was audited) instead of repeating free-text model_name/model_version on every row. Per ADR-0007, ACDM holds the model's IDENTITY and GOVERNANCE VERDICT only — NOT its pipeline (features, hyperparameters, training data, metrics), which stays in the institution's MLOps tooling. Defined here in the foundation (like GeographicRegion) so prospect_research (Score), campaigns (Segment), and ai (AgentAction) can all reference it without an import cycle.
19 fields in the beta explorer
Note
A free-text note ABOUT some record, attachable to ANY entity via the polymorphic `about` (the record's id) + `about_type` (its entity kind). The general-purpose note mechanism; the existing entity-specific *_notes slots remain for inline convenience. Mixes in MachineGenerated so an agent-drafted note is distinguishable from a human's.
23 fields in the beta explorer
Source Value
The VERBATIM value a source system held for one of this record's fields, preserved for traceability when ACDM standardized that field onto an enum (or it fell to `other`). A small inlined value (like MonetaryAmount / ExternalIdentifier), NOT an entity in its own right. `for_slot` names the ACDM slot the raw value belongs to (e.g. "gift_type"); `source_value` is the literal source code/label (e.g. "EFT"). The system it came from is the record's Auditable.source_system, so it is not repeated here. PASSTHROUGH, NOT TRUTH (governance): this is lineage/audit only. Consumers MUST NOT branch on it; read the STANDARDIZED slot (e.g. gift_type) for logic, because a raw source code means nothing across institutions and keying logic off it reintroduces the vendor lock-in ACDM exists to remove. It earns its place only so a canonical ACDM record stays self-describing after the source system is gone (same-system round-trip, reconciliation, and human resolution of values that mapped to `other`). It deliberately does NOT make cross-system migration lossless: if a distinction must survive into a DIFFERENT target system, MODEL it (a richer enum value or a structural slot), do not rely on this. The first facet of the planned field-level provenance pattern (roadmap P3-3), alongside as_of_date / confidence.
2 fields in the beta explorer
Tag
An ad-hoc, user-applied LABEL for grouping a record ("connector", "gala-2026-lead", "loyal-volunteer"), with an optional `tag_category` namespace and light provenance (`tagged_date` / `tagged_by` / `tag_source`). A small inlined value (like SourceValue / ExternalIdentifier), NOT an entity. NON-CANONICAL — the bounded escape hatch of ADR-0004, sharing the do-not-branch fence with SourceValue. Two rules: (1) do NOT branch standardized logic on a tag (read the modeled slot); and (2) do NOT use a tag to encode a concept ACDM already models — the tag-vs-concept test: - "alumnus" / "parent" -> Affiliation / ConstituencyType - "major donor" / "hot prospect" -> Score - "board member" / "class agent" -> VolunteerRole - "President's Circle" -> GivingSociety / SocietyMembership - "do not mail" -> consent / ContactRestriction - "interested in athletics" -> Affinity (structured interests) - "FY26 year-end audience" -> Segment Tags sit at the BOTTOM of the specificity ladder (required enums/entities -> extensible enums / free text -> tags, the residue): use them only for labels no modeled concept fits. NOT a substitute for the structured Affinity.
5 fields in the beta explorer
Gift Aid (UK) 1 entity
UK Gift Aid declarations and claims.
Gift Aid (UK) 1 entity
UK Gift Aid declarations and claims.
Gift Aid Declaration
A UK Gift Aid declaration made by a constituent, declaring that they pay sufficient UK Income and/or Capital Gains Tax to cover the tax reclaimed by the institution on their donations.
17 fields in the beta explorer
Gifts & giving 16 entities
Gifts, pledges, payments, and recurring giving — the money and the promises.
Gifts & giving 16 entities
Gifts, pledges, payments, and recurring giving — the money and the promises.
Benefit Item
A catalog item for a donor benefit or premium (tote bags, umbrellas, shirts, etc.) with a unit cost and fair market value.
16 fields in the beta explorer
Deposit
A MONEY-ONLY bank-reconciliation grouping: the actual funds banked together in one deposit — the seam a finance team reconciles against the bank statement and hands to accounting. Carries the banked total (deposit_total), an optional deposit-grain fee total, and an optional OPAQUE gl_reference handoff key, so gift records tie out to the deposit and the deposit ties out to the bank. Holds MONEY-MOVEMENT transactions only (a pledge has no place here); membership is by an optional `deposit` back-reference on Gift (including pledge-payment gifts). Distinct from RevenueBatch (the entry-control grouping). Models NO general-ledger structure — no GL accounts, no chart of accounts, no journal entries, no fund balances; ACDM records what was banked and where it landed, the accounting system stays the authoritative ledger. See ADR-0013.
18 fields in the beta explorer
Gift
A single charitable transaction received by the institution. Maps to a CASE "gift" for counting. full_amount is the gross received; charitable_amount (full minus premium) is the deductible portion. WHO gets credit is on the `donors` (GiftDonor) records; WHERE the money goes is on the `allocations` (GiftAllocation) records.
47 fields in the beta explorer
Gift Adjustment
A correction applied to a gift or pledge AFTER the fact: a refund, a reversal, a reclassification, or a pledge write-off. Adjustments are their OWN records and never mutate the original gift's amounts, so the audit trail and the original counting stay intact; CASE counting NETS adjustments downstream (a refund or reversal reduces counted Funds Received; a write-off reduces a pledge's outstanding commitment). Inlined on the Gift/Pledge it adjusts.
16 fields in the beta explorer
Gift Agreement
The legal agreement governing a major or endowed gift: what it establishes, its terms and donor restrictions, the reporting obligations back to the donor, and its signed / executed lifecycle. Links to the donor, the Designation it establishes (e.g. an endowed scholarship), and the Fund it is held in. The signed document itself is a Document (about this agreement); the reports it requires can be tracked as Documents / downstream.
23 fields in the beta explorer
Gift Allocation
One line of a gift's / pledge's designation split: an amount directed to a designation. One-or-more per Gift/Pledge (inlined); together they sum to the charitable total. Replaces the single `designation` for split gifts; the flat `designation` remains the primary-designation Core convenience.
3 fields in the beta explorer
Gift Benefit
The link between a specific Gift and a BenefitItem selected by the donor, including quantity and fulfillment status.
17 fields in the beta explorer
Gift Donor
How a party is associated with a gift or pledge, and the CREDIT they receive. One-or-more per Gift/Pledge (inlined). The `donor_role` says HOW they are tied to it: a primary / joint / group donor (who carries credit), or an in_memory_of / in_honor_of honoree (a non-giving party, no amounts). The four amounts are the distinct CREDIT types advancement tracks: legal (hard / receipted), soft (recognition credit to an influencer who did not legally give, e.g. a spouse or a foundation's principal), recognition (giving-society credit), and campaign (amount counted toward a campaign). Each party also carries their affiliation AS OF the gift date (donor_constituency) for source-based counting, and a per-party anonymity flag. Absorbs the former SoftCredit. For a TRIBUTE association (donor_role in_memory_of / in_honor_of) the party (constituent or honoree_name) is the honoree, and the notify_* fields capture who to inform (e.g. the family) and the message to convey; whether the notification was actually sent is downstream fulfillment, not stored here.
24 fields in the beta explorer
Gift In Kind Asset
The physical details of a non-monetary asset (artwork, real estate, equipment, etc.) donated as a Gift-in-Kind.
20 fields in the beta explorer
Gift Proposal Attribution
One line attributing a portion of a gift to a Proposal it closed: a proposal + the amount of THIS gift credited to closing it. Zero-or-more per Gift (inlined). Unlike GiftAllocation, attributions are NON-EXHAUSTIVE — they sum to <= the gift total, because part of a gift may answer no formal ask — and are independent of the designation split. A gift can close several proposals (the "triple ask") and a proposal can be satisfied by several gifts over time; this is the many-to-many link that carries the amount. The flat `proposal` remains the primary/originating proposal Core convenience.
3 fields in the beta explorer
Matching Gift
An employer (or other) gift that matches a constituent's original gift.
15 fields in the beta explorer
Matching Gift Claim
A pending matching gift claim submitted to an employer by a donor requesting a matching contribution for their gift.
18 fields in the beta explorer
Pledge
A commitment to give a total amount over time. The committed total (total_amount) counts toward CASE New Funds Committed. Each installment that satisfies the commitment is a real Gift whose `pledge` points back here (a "pledge payment"), counted once toward CASE Funds Received via Gift.full_amount — exactly as a sustainer charge is a Gift pointing at its RecurringGift. The Pledge carries the same donor credit (donors) and designation split (allocations) as a Gift, but that credit is COMMITTED credit: donor credit on a Pledge counts with New Funds Committed, donor credit on the installment Gifts counts with Funds Received, and the two are NEVER summed together (committed-vs-received discipline; docs/guides/business_rules.md §8). `scheduled_payments` is the EXPECTED / receivable forecast; the money actually received lives on the Gifts.
24 fields in the beta explorer
Recurring Gift
A sustainer / recurring-giving commitment: an open-ended schedule that charges a fixed recurring_amount on a frequency (monthly, ...) until paused, cancelled, or lapsed. Distinct from a Pledge (which commits a fixed TOTAL over a set number of installments); a sustainer has no fixed total. Each charge is recorded as a real Gift whose `recurring_gift` points back here, so the money counts as Funds Received once via the gifts module. Card-on-file is a TOKEN reference only (payment_token); ACDM never stores card or account numbers.
25 fields in the beta explorer
Revenue Batch
A DATA-ENTRY control grouping: the transactions keyed together in one sitting, reconciled to a control count + control total BEFORE posting. Type-agnostic — one batch can hold gifts (including pledge-payment gifts), pledges, and adjustments together (so "GiftBatch" would mislead); membership is by an optional `batch` back-reference on each transaction, NOT a heterogeneous member list (Decision 4). This is the ENTRY seam (does the keying reconcile?), distinct from Deposit, the BANK seam (does the money reconcile against the statement?): a pledge belongs in a RevenueBatch (a keyed transaction) but not in a Deposit (no money moved). The entry-control lifecycle (posted_status) is NOT a general-ledger posting structure. See ADR-0013.
19 fields in the beta explorer
Scheduled Payment
One EXPECTED installment in a pledge's payment schedule: a due date and the amount due, optionally split to a designation. This is the FORECAST / receivable side: with only `expected_payments` (a count) the model could not drive pledge reminders or pledge-receivable forecasting; the schedule supplies the due dates + amounts those need. Inlined on Pledge; together the scheduled installments sum to the pledge total_amount. Whether an installment is `paid` is a status here; the money that satisfies it is a real Gift whose `pledge` points back at the commitment (counted once toward Funds Received via Gift.full_amount).
6 fields in the beta explorer
Goals & metrics 2 entities
Goals, scores, and the numbers that track performance.
Goals & metrics 2 entities
Goals, scores, and the numbers that track performance.
Goal Qualifier
A structured dimension/value scope on a PerformanceGoal — the difference between "recruit 30 donors" and "recruit 30 PARENT donors", or "$50k" and "$50k to the SCHOLARSHIP designation". `dimension` (an extensible GoalDimension) names the operational slot the downstream metrics layer filters on; `value` is the filter value (mapped via mappings/ where institution-specific). Multiple qualifiers on one goal are ANDed — "30 parent donors IN the Northeast" is two qualifiers, both of which must hold. The qualifier also names the population/denominator a rate target is measured over (design D2/D10). NO achieved count or amount is stored here; the actual is derived downstream (design D11, ADR-0014).
3 fields in the beta explorer
Performance Goal
A performance target set for an individual or a unit/team for a given period — e.g. "$2.5M raised in FY26", "150 visits", "30 proposals". The grain is subject x metric_type x period. Only the TARGET is stored; the actual achieved value is computed from gifts and interactions, not held here.
27 fields in the beta explorer
Grants 3 entities
Grant seeking and awards from foundations and funders.
Grants 3 entities
Grant seeking and awards from foundations and funders.
Grant
A foundation, corporate, or government grant: the funded (or sought) award, its lifecycle, its purpose, and the period it covers. An awarded grant_amount counts toward CASE New Funds Committed; the money arrives through GrantPayments that each link to a real Gift. The funder is an Organization; the funder's contact is the program_officer. The reports the funder requires back are GrantReports.
26 fields in the beta explorer
Grant Payment
A scheduled (and, once received, realized) installment of a grant. The scheduled_* fields are the payment schedule; when the installment arrives, received_gift points at the Gift that recorded it, so the amount counts as CASE Funds Received exactly once (via Gift.full_amount) and never double-counts the grant's committed total. Mirrors a pledge payment (a Gift with `pledge` set) and PlannedGift.realized_gift.
15 fields in the beta explorer
Grant Report
A reporting deliverable the funder requires back (a financial or narrative report, interim or final), with its due date and status. The compliance / stewardship obligation that distinguishes a grant from an ordinary gift; fulfilling it is how the grant relationship is stewarded toward renewal.
15 fields in the beta explorer
Impact 3 entities
Outcomes and the evidence of what giving achieved.
Impact 3 entities
Outcomes and the evidence of what giving achieved.
Impact Indicator
The DEFINITION of an outcome metric a program tracks — the mission-side analog of PerformanceGoal (which defines a fundraising target). Names the metric, its unit, target, and baseline; OutcomeMeasurements record dated results against it. Carries related_mappings to IRIS+ so a program's indicators align to the sector's standardized impact-metrics catalog (see mappings/standards/iris-plus.yaml).
17 fields in the beta explorer
Outcome Measurement
A dated, measured result for an ImpactIndicator — recipient-level (one person's outcome) or program-level (an aggregate, no recipient). Mixes in Provenanced so every measurement carries `as_of_date` + `confidence`, the same volatile-fact provenance ACDM uses for scores and wealth. Aligns to IRIS+ by crosswalk; no benchmark metric value is hard-coded — counting / derivation stays downstream.
20 fields in the beta explorer
Service Delivery
A single, countable unit of service delivered — the mission-side analog of a Gift, the atomic transaction "meals served", "nights of shelter", and "sessions delivered" roll up from. Modeling it explicitly (not as an Interaction or a note) is what makes the count first-class, queryable, and reportable. A `quantity` + `unit_of_service` lets one row carry a count; `recipient` is optional so an aggregate / anonymous count (a meal line) still records.
20 fields in the beta explorer
Major gifts pipeline 2 entities
Opportunities, proposals, and the moves that carry a major gift to close.
Major gifts pipeline 2 entities
Opportunities, proposals, and the moves that carry a major gift to close.
Opportunity
A potential major gift worked through the cultivation pipeline — the prospect/relationship record. Carries the moves-management `stage`, an open/closed `opportunity_status`, a probability, expected and actual close dates, the managing `officer`, and what it is designated to fund. It holds NO dollar amounts: the ask lives on its Proposals (the ask lifecycle), and an opportunity's ask / expected / funded totals are DERIVED by rolling up the proposals and gifts attributed to it (via Proposal.opportunity) — forecasting is done through proposals. The contacts that advance it are Interactions (engagement.yaml) linked via their `opportunity`; the formal written asks are Proposals; the gift that closes it is attributed back via Gift.opportunity.
26 fields in the beta explorer
Proposal
A formal written ask within an Opportunity: the request put to a prospect for a specific purpose, with its own ask lifecycle. The ask moves through planned -> original -> adjusted ask amounts (each with its date), then a committed_amount when the donor commits, and a DERIVED received_amount rolled up from the gifts attributed to it (see Gift.proposal_attributions). This is where forecasting lives — an early forecast is a `draft` Proposal carrying a planned_ask_amount — and the entity the metrics.yaml `proposals` metric counts.
30 fields in the beta explorer
Non-giving activity 2 entities
Ways constituents engage beyond giving — volunteering, attendance, participation.
Non-giving activity 2 entities
Ways constituents engage beyond giving — volunteering, attendance, participation.
Clinical Encounter
A HIPAA-compliant record of a clinical/medical service event. Tracks treating facility, department, physician, and dates, with comments limited to non-clinical context, supporting Grateful Patient fundraising.
18 fields in the beta explorer
Commercial Transaction
A record of auxiliary/commercial transactions (bookstore purchases, sports tickets, parking fees, journal subscriptions) used to analyze constituent affinity.
18 fields in the beta explorer
Organizations 2 entities
Companies, foundations, and the other institutions you work with.
Organizations 2 entities
Companies, foundations, and the other institutions you work with.
Institution
The educational institution that owns this advancement data: the tenant anchor its OrganizationalUnits roll up to. Beyond its name it carries the defaults reporting leans on: `country`, `fiscal_year_start_month` (anchors the model's fiscal_year integers), `institution_type` (the IPEDS control category), `default_currency`, and `timezone`. Stable external keys (an IPEDS UnitID, a CASE / CDS id) ride on `external_identifiers`; the full Reconcilable merge machinery (merged_from / is_golden) is deliberately omitted, since the institution is a singleton that is never deduplicated. It declares the `institution_namespace` that scopes this tenant's `global_id`s (ADR-0008) and carries its own `global_id`; `supersedes_global_id` is omitted for the same singleton reason.
20 fields in the beta explorer
Organizational Unit
A school, college, department, division, program, region, or office within the institution. The roll-up spine the rest of the model references (EducationRecord.school_or_college, the shared `organizational_unit` slot, PerformanceGoal.goal_subject, and the owner of events / membership programs / volunteer groups). Self-referential via `parent_unit` so units form a hierarchy (e.g. a Department under a College), mirroring parent_fund / parent_campaign.
15 fields in the beta explorer
People & organizations 11 entities
The people and organizations at the heart of every relationship.
People & organizations 11 entities
The people and organizations at the heart of every relationship.
Affiliation
A constituency/affiliation a person holds with the institution — alum, parent, student, faculty, friend, etc. A person may hold SEVERAL at once (e.g. a current student who is also the child of an alum, or an alum who is also a parent), so affiliations are multivalued and each carries its own (possibly year-only) timeframe and an `is_primary` flag. This is the structure behind source-based reporting such as the CASE VSE donor-source breakdown; WHICH affiliation is "primary" when several apply is institution-specific (see mappings/), per the ACDM rule of standardizing the structure, not the values.
21 fields in the beta explorer
Affinity
A constituent's interest / affinity in some area: a sport, an academic discipline, a cause, an art form, an activity. Used for segmentation and matching (which prospects care about the rowing campaign, the marine-biology fund, climate). This is the STRUCTURED interests/affinities concept, a recognized advancement signal, and is deliberately distinct from the future generic Tag escape hatch (see ADR-0004's tag-vs-concept test): the specific area is free text (institution-specific, mapped via mappings/) while affinity_type groups it. Mixes in Provenanced so an INFERRED affinity (from a model or behavior) can carry confidence + as_of_date.
18 fields in the beta explorer
Demographics
Sensitive DEI / equity demographics for a person, kept in a SEPARATE, governance-gated sub-record (one per Person, inlined) so it is easy to restrict or redact and does not scatter sensitive fields across Person. ACDM provides the PLACES; it does NOT prescribe value lists (ethnicity is free text, mapped via mappings/) because the categories are institution- and country-specific. GOVERNANCE: collect only with consent and a lawful basis, gate access, never require. `full` subset throughout.
17 fields in the beta explorer
Education Record
A credential a person earned (or is pursuing) at the institution — a degree, certificate, microcredential, or continuing-/professional-education program. Multivalued on Person because people accumulate several over a lifetime (a bachelor's, then a graduate certificate earned online years later). This is the structured replacement for the former free-text `degrees` field, and it mirrors the Affiliation pattern: an inlined sub-record on Person plus a `constituent` back-reference, each carrying its own (possibly year-only) date. The record is a FACT ("earned X"); whether a given credential makes someone an `alumnus` vs `former_student` for source-based reporting is an institution-specific roll-up that lives on Affiliation + mappings/ (ACDM standardizes the structure, not the rule). `credential_type` and `education_modality` are modeled deliberately because online and continuing-/professional-education completers are the fast-growing population the "who counts as alumni" question turns on — the CASE VSE donor source and the AEM alumni-of-record denominator both depend on it.
22 fields in the beta explorer
Employment
A constituent's employment at an employer: where a person works (or worked), their title, and the industry. Multivalued on Person because people hold several jobs over a lifetime and sometimes at once. Mirrors the Affiliation / EducationRecord pattern: an inlined sub-record on Person plus a `constituent` back-reference, each carrying its own (possibly year-only) timeframe and an `is_primary` flag. Employment is the hinge for three things advancement cares about: matching gifts (MatchingGift.matching_organization is typically the donor's primary employer), corporate relations, and capacity (title, industry, and income feed prospect research). The `employer` is a REFERENCE to an Organization, so one employer record is shared across all its employees (and can itself be a matching-gift company), exactly like a shared Address.
23 fields in the beta explorer
Formatted Name
A composed name STRING used to address the constituent in correspondence — CATEGORY TWO of advancement naming. This is the advancement addressee / salutation concept: an `addressee` is how the envelope / inside address reads ("Dr. Jane M. Smith", "Mr. and Mrs. Smith"); a `salutation` is how a letter greets ("Dear Dr. Smith", "Dear Janie"). A constituent has MANY, so it is multivalued — on Person for individual forms and on Household for joint / unit-level forms (e.g. the couple's "Mr. and Mrs." name belongs to the giving unit). Each form varies along two orthogonal dimensions — `name_formality` (formal vs casual) and `name_cardinality` (individual vs joint vs household). An institution's own catalog label for a form ("Casual Joint", "Casual Individual") is a VALUE, not structure: it lives in the free `format_label` slot and is mapped via mappings/, per the ACDM rule of standardizing the structure and leaving institution-specific values open — do NOT enumerate those labels. `addressed_by` carries personalization: when set, this is how a PARTICULAR sender (e.g. a dean or gift officer) addresses the constituent ("the Dean writes 'Dear Janie'"); when absent, the form is a general-purpose one selected by use/formality/cardinality. HOW a joint string is composed from two people's parts, and when a joint form drops to individual (a deceased spouse), are derivation policy applied downstream — ACDM stores the form and its dimensions, not the composition rule. Unlike PersonName this carries no `constituent` back-reference because it is a pure inlined child of whichever owner (Person or Household) holds it.
20 fields in the beta explorer
Household
A giving unit grouping people who are counted together (e.g. spouses). Used for household-level giving totals and solicitation.
26 fields in the beta explorer
Organization
A company, foundation, or other organization (e.g. a matching-gift employer or grant-making foundation). Beyond its name and high-level kind it carries an organizational profile: `organization_type` is the kind (corporation / foundation / government / ..., also the basis for organization-source reporting); `industry` is the finer industry bucket for a corporation; web, size, and financial signals (`website`, `founded_date`, `employee_count`, `annual_revenue`, `ticker_symbol`) support corporate-relations and capacity segmentation; and `parent_organization` is a self-reference for corporate family trees and matching-gift parent-company roll-ups. Tax / registry IDs (EIN, DUNS, ...) ride on `external_identifiers` (the MDM pattern), not bare slots.
43 fields in the beta explorer
Person
An individual person — alum, parent, friend, faculty, or staff.
64 fields in the beta explorer
Person Name
A structured personal name a person holds — the legal name of record, the name they prefer, a maiden/birth name, a former name, or an alias. This is CATEGORY ONE of advancement naming: the atomic NAME PARTS (prefix, given, middle, family, suffix, credentials) of who the person IS, as distinct from the composed correspondence strings in FormattedName. Multivalued on Person because people carry several names over a lifetime (a maiden name that becomes a former name after marriage; a professional alias). Mirrors the Affiliation / EducationRecord pattern: an inlined sub-record on Person plus a `constituent` back-reference, each carrying its own (optional) validity span. Person also keeps the flat `first_name` / `last_name` / `preferred_name` slots as the denormalized PRIMARY/display name (the Core convenience small shops need, and what staff.yaml reuses) — exactly the denormalization pattern used by `class_year` (vs EducationRecord) and `primary_constituency` (vs Affiliation). Reuse the shared `first_name` / `last_name` / `prefix` / `suffix` slots here so a name's parts map identically wherever they appear.
28 fields in the beta explorer
Relationship
A directed relationship between two constituents (spouse, parent, employer, board member, …). Beyond the bare from→to→type, it carries the relationship-level facts both CRMs track: a `relationship_category` that groups the extensible `relationship_type` for reliable roll-up (so any institution's "Husband" / "Wife" / "Domestic Partner" type still reads as `spousal`), the `joint_gift_credit` / `joint_mailing` flags that drive household giving and solicitation, a `relationship_status` and validity span, and a `reciprocal_relationship` pairing the inverse record (A→B spouse ↔ B→A spouse). The joint-credit / joint-mailing semantics that previously lived implicitly in Household + GiftDonor are now explicit here; the authoritative per-gift credit split still lives on GiftDonor (this is the default).
22 fields in the beta explorer
Planned giving 2 entities
Bequests, trusts, and gifts planned for the future.
Planned giving 2 entities
Bequests, trusts, and gifts planned for the future.
Planned Gift
A deferred/estate gift commitment (bequest, trust, gift annuity, …), carrying its vehicle, valuation (face vs. present value), revocability, and expectancy->realized lifecycle. When realized, `realized_gift` links the Gift actually received so it counts as Funds Received without double-counting the expectancy.
28 fields in the beta explorer
Planned Gift Beneficiary
A payee or measuring life of a trust or annuity.
16 fields in the beta explorer
Portfolios 3 entities
Officer portfolios and who manages which relationships.
Portfolios 3 entities
Officer portfolios and who manages which relationships.
Assignment
The assignment of a prospect to a gift officer: the typed, time-bounded link that is the portfolio history. `assignment_type` says in what capacity (primary / secondary manager, solicitor, stewardship); the dates bound it (an open assignment_end_date means current); `assigned_by` records who made it. It also carries the prospect's qualification OUTCOME: `qualification_status` (identified → qualifying → qualified / disqualified / withdrawn) plus the reason a prospect was ruled out (`disqualified_reason`) or pulled from cultivation (`withdrawn_reason`). The state-change TRAIL behind the current status is ProspectHistory.
21 fields in the beta explorer
Gift Officer
A staff member who manages a portfolio of prospects. A kind of StaffMember (internal personnel), NOT a Constituent. `portfolio` is the denormalized list of who they manage; the typed, time-bounded links are Assignments. Targets live on PerformanceGoal (a GiftOfficer is a valid goal_subject).
24 fields in the beta explorer
Prospect History
One entry in a prospect's qualification lifecycle trail: a recorded change of `qualification_status` for a prospect (optionally under a given officer), with the change date and the reason. The light state-change history behind Assignment's CURRENT qualification_status, so the path identified → qualifying → qualified / disqualified / withdrawn — and WHY — can be reconstructed for analytics and the AI "what happened" view. ACDM stores the trail, not the pipeline-stage policy.
18 fields in the beta explorer
Privacy 2 entities
Data protection, retention, and privacy requests.
Privacy 2 entities
Data protection, retention, and privacy requests.
Access Event
A single read/ACCESS EVENT over advancement data — the access-side companion to DataSubjectRequest. It records WHO accessed (a User or an Agent, via the shared Actor seam), WHOSE data / WHICH record, WHAT sensitivity tier, WHEN, WHY, and WHAT action — the evidence a Data Protection Officer needs for the GDPR Art. 30 record of processing activities and the FERPA §99.32 record of each request for and disclosure of PII from a student's education records. This is an access-EVENT record, explicitly NOT an access-CONTROL or access-ENFORCEMENT record: it models no role, permission, grant, RBAC/RLS predicate, deny decision, or masking directive, and deciding WHETHER access is permitted stays downstream application policy ("store the record, not the rule"). It records THAT access happened and its salient facts — mirroring the DataSubjectRequest "log the request, not the execution" boundary exactly. The actor is `accessed_by` (range Actor — covering a human/service `User` and an automated `Agent` with no new seam, symmetric with created_by / modified_by / owner). What was accessed is identified by `constituent` (the optional data subject) plus `accessed_record_type` / `accessed_record_id` (the specific record) and optional `accessed_field` (field-level logging); at least one of `constituent` or `accessed_record_id` SHOULD identify what was accessed (normative, not structurally enforced — access to an already-erased subject must still be recordable). `classification_accessed` records the sensitivity tier (mirroring the `security_classification` annotation vocabulary, not modifying it). `accessed_at` is the true event time (distinct from the `Auditable` write-provenance stamps, so batch-logged events keep the real access time). Since it is Auditable, the access log is itself retention-governed.
21 fields in the beta explorer
Data Subject Request
An AUDITABLE LOG of a constituent exercising a data-subject privacy right (GDPR Art. 15-21 / CCPA) and how the institution handled it — the right invoked, the subject, identity verification, the statutory clock, the accountable handler, the lifecycle status, and the disposition. This is the evidence a Data Protection Officer must be able to produce (GDPR Art. 12/30, CCPA §1798.130). This is the request RECORD, NOT an erasure-EXECUTION record: it does not model the per-field PII cascade or enumerate which records were deleted / anonymized — that is downstream application policy ("store the record, not the rule"). The disposition is captured by `request_status` and free-text `disposition_notes`; when erasure is denied or only partly fulfilled because data must be kept, `processing_basis` (reused — typically `legal_obligation`) records the lawful ground for what was retained. The data subject is referenced via `constituent`; `subject_name` is a free-text fallback for a requester who is not (or is no longer) a tracked Constituent. At least one of the two SHOULD identify the subject (normative, not structurally enforced — a request about an already-erased subject must still be recordable). This is the privacy-rights-workflow home, distinct from consent.yaml's communication-consent / contact-preferences remit.
25 fields in the beta explorer
Programs 3 entities
The programs and services your organization delivers.
Programs 3 entities
The programs and services your organization delivers.
Program
A charitable initiative the organization runs (a food program, a shelter program, a youth-mentoring program). The mission-side analog of Campaign — a funded initiative — with `funded_by -> Designation` the key bridge that ties what a program SPENDS to the restricted funds that PAY for it, closing the raised<->delivered loop in one graph. Owned by an OrganizationalUnit; its type rolls up to the NTEE subsector via ProgramType.
21 fields in the beta explorer
Program Enrollment
A served person's participation in a Program — the per-person association, mirroring the MembershipProgram / Membership idiom. Links a ServiceRecipient to the Program they are enrolled in, with an optional enrollment window and current standing. ACDM records the enrollment FACT; sequencing rules (e.g. "eligibility precedes enrollment") are app policy, not a schema constraint.
16 fields in the beta explorer
Service
A specific service offered within a Program — the optional finer grain below a program (a program offers several services). Names the countable `unit_of_service` (e.g. "meal", "bed-night", "counseling session") that a ServiceDelivery (impact.yaml) records one or more of.
16 fields in the beta explorer
Prospect research 2 entities
Capacity, affinity, and the research that finds the next big gift.
Prospect research 2 entities
Capacity, affinity, and the research that finds the next big gift.
Score
A single typed score or rating for a constituent: capacity, affinity, inclination, lead, propensity (incl. ML), planned-giving likelihood, or priority. One shape for all of them. The value is expressed in whichever form fits the type: `score_amount` for a dollar capacity, `score_value` for a numeric score (e.g. 0-1 or 0-100), or `score_band` for a letter/label grade (A/B/C, High/Medium/Low); `score_scale` says how to read it. `score_source` says whether a person, a vendor, or a model produced it; for a model, the light provenance fields (model_name / model_version / confidence) make the prediction traceable, and `produced_by_model` optionally anchors them to an auditable ModelVersion record (ADR-0007). ACDM holds the score, NOT the model or its pipeline.
24 fields in the beta explorer
Wealth Indicator
A discrete piece of wealth/capacity EVIDENCE for a constituent (real estate, securities, business ownership, known income, foundation affiliation, political giving, ...), usually from prospect research or a screening vendor. The descriptive facts behind a capacity Score; ACDM stores the evidence, the capacity conclusion is a Score (often source = vendor or model).
18 fields in the beta explorer
Recognition & societies 3 entities
Giving societies, naming, and how donors are recognized.
Recognition & societies 3 entities
Giving societies, naming, and how donors are recognized.
Award
An honor or award a constituent RECEIVED from the institution — a distinguished-alumnus award, a service or volunteer award, a hall-of-fame induction, recognition of an honorary degree. The recipient is the shared `constituent`. Distinct from a GivingSociety / SocietyMembership (recognition CONFERRED BY GIVING) and from stewardship.ScholarshipAward (financial aid the constituent received as a BENEFICIARY): this is HONOR recognition OF the person, an alumni-engagement signal. It replaces having only free-text `VolunteerRole.recognition`. Slot names are honor-specific (conferred_date, award_standing, …) to stay clear of the scholarship `award_*` slots.
19 fields in the beta explorer
Giving Society
A donor recognition society — the DEFINITION of a named recognition program (a President's Circle, a 1868-style lifetime society, a loyalty society, a Legacy/Heritage planned-giving society). Carries only its name and type; the giving thresholds that qualify a donor for it (and for each level) are institution POLICY recorded in mappings/, deliberately NOT stored here, since qualification is a derived roll-up (see module header).
14 fields in the beta explorer
Society Membership
A constituent's standing in a GivingSociety — the THIN, non-derivable core of society membership. Current qualification (does their cumulative/annual giving meet the threshold this year?) is derived downstream from gifts; what is stored here is what CANNOT be recomputed: the induction date, the conferred level, whether membership is honorary or a permanent lifetime conferral, the current stored standing, and the donor's honor-roll listing preference (`recognition_name` + `list_publicly` — the recognition analogue of Gift.anonymous). The member is the shared `constituent`.
21 fields in the beta explorer
Reporting 1 entity
Definitions and structures for consistent reporting.
Reporting 1 entity
Definitions and structures for consistent reporting.
Reporting Figure
One EXTERNAL reporting input — a number a standardized return needs but ACDM cannot derive from gift/constituent facts (the alumni-of-record denominator, endowment market value, enrollment, a prior-year restatement). It identifies the figure (`figure_key` against `ReportingFigureType`, `reporting_standard` against `ReportingStandard`), carries exactly one typed value (`figure_amount` | `figure_count` | `figure_rate`), states the reporting period (`fiscal_year`, optionally precise `period_start`/`period_end`), an optional scope (`figure_qualifiers`, `organizational_unit`), and its provenance (`as_of_date` from Provenanced + a free-text/URI `figure_source`). REPORTING-SNAPSHOT grain, not interchange (ADR-0014): a point-in-time reported value, fenced out of every depth profile (specialized) and beside the interchange core, not inside it. Standardizes SHAPE + PROVENANCE only — ACDM prescribes NO computation or formula for the value (mirrors EngagementProfile / prospect_research.Score; AGENTS.md convention #6). Carries ONLY figures the case-vse.yaml crosswalk marks `external_input`. A figure ACDM can derive (total support, donor count, the participation numerator) is NEVER a ReportingFigure — it is computed from facts. The participation RATE is derived (facts numerator / this denominator), not stored, except an externally-published rate that cannot be recomputed.
25 fields in the beta explorer
Staff & users 2 entities
Your team: staff, assignments, and the users who work the system.
Staff & users 2 entities
Your team: staff, assignments, and the users who work the system.
Staff Member
A person employed by (or contracted to) the institution to do advancement work — gift officers, prospect researchers, annual-fund and advancement- services staff, leadership. NOT a Constituent. If a staff member is also a constituent (e.g. an employee who is also an alum/donor), link the two via `constituent_record` rather than duplicating the person.
21 fields in the beta explorer
User
A system account that signs in and acts in advancement software — the thing that owns records, authors interactions, and carries permissions. The concrete `Actor` in ACDM: it is what `created_by`, `modified_by`, `owner`, and `Interaction.author` point to. Usually backed by a StaffMember (`staff_member`); a User with no `staff_member` is a service / integration account.
17 fields in the beta explorer
Stewardship 3 entities
Thanking donors and honoring the promises behind each gift.
Stewardship 3 entities
Thanking donors and honoring the promises behind each gift.
Naming Opportunity
A named physical asset or endowed position (building, room, wing, chair, etc.) funded by donor gifts and established in recognition of their stewardship.
19 fields in the beta explorer
Scholarship Award
A scholarship or financial-aid award made TO a constituent (the recipient) from a financial-aid Fund/Designation — the beneficiary mirror of a Gift, and the join that closes the donor-stewardship loop. ACDM models the award only as that stewardship link (who received support from which fund), NOT as a financial-aid system of record: eligibility, need analysis, and disbursement accounting live in the SIS / financial-aid system. FERPA-sensitive, so the whole class is in the `full` subset; sharing a recipient's identity or message with the fund's donor additionally requires a StewardshipConsent.
20 fields in the beta explorer
Stewardship Consent
A recipient's recorded consent to be stewarded toward a donor — e.g. to be identified to the donor of their scholarship and to share a thank-you message, story, or photo. This is RELEASE / testimonial consent: the constituent grants permission for THEIR identity and words to be shared OUTWARD with a donor. It is deliberately separate from consent.yaml's CommunicationPreference (which governs whether WE may contact the constituent). Each grant carries a type, a status, an optional scholarship_award scope, and an expiry, so FERPA written consent is auditable and time-bounded. `full` subset.
19 fields in the beta explorer
Strategy 1 entity
Plans, initiatives, and the strategic frame around the work.
Strategy 1 entity
Plans, initiatives, and the strategic frame around the work.
Initiative
A STRATEGY: a named, time-bounded advancement effort with a stated rationale and an owning staff member — "Grow the West-Coast major-gift pipeline", "Re-engage lapsed young alumni", or an annual fund modeled as a strategy. Under one Initiative sit HETEROGENEOUS tactics — a cultivation Event, a regional Campaign, a host committee (VolunteerGroup), a set of Opportunities, an Appeal, a GivingSeason — each pointing back via the shared `serves_initiative` slot, so strategy -> tactic -> outcome is traceable in DATA, not free text. DISTINCT from Campaign (design D3): a Campaign is a SOLICITATION EFFORT (dollar `campaign_goal`, gifts attach via Appeal); an Initiative is the STRATEGY those efforts serve. Initiative therefore carries NO `*_goal` slot — giving it one would re-create the campaign/performance-goal conflation the metrics.yaml header guards. Its TARGETS are `PerformanceGoal`s whose `goal_subject` is this Initiative (metrics.yaml); its OUTCOMES derive from the tactics that serve it. Self-references via `parent_initiative` so strategies nest (a sub-strategy under a portfolio strategy), mirroring parent_campaign / parent_unit / parent_goal.
19 fields in the beta explorer
Tasks 1 entity
The to-dos and follow-ups that keep relationships moving.
Tasks 1 entity
The to-dos and follow-ups that keep relationships moving.
Task
A standalone to-do / action item — distinct from `Interaction.next_action`, which folds the next step into a completed contact report. A Task is the first-class, assignable, status-tracked unit of PENDING work an officer (or an AI "what's next" agent) queues and clears. The ASSIGNEE is the Auditable `owner` (the actor currently responsible; reassignable). What the task concerns is the polymorphic `about` (a record id) + `about_type` (its kind: "Opportunity", "Gift", "Constituent", …), the same mechanism as Note / Alert; the optional typed `constituent` names the prospect directly for the common case. Working a task often PRODUCES an Interaction (the completed contact); ACDM does not link the two here — the Interaction stands on its own.
21 fields in the beta explorer
Travel 1 entity
Trips and visits, planned and logged.
Travel 1 entity
Trips and visits, planned and logged.
Trip
One fundraising trip: the thin planning + accountability CONTAINER that groups the visits made on it so the trip can be approved, costed, and measured as a unit. Carries the managing `officers` (multivalued — joint calls are common), a `trip_purpose`, the `geographic_region` (+ free-text `destination`), a `start_date`/`end_date` window, an authored cost (`budget_amount` / `actual_cost`, the inputs to travel ROI), an optional `campaign` scope (the "why this trip"), and a `trip_status` lifecycle — requested -> approved -> in_progress -> completed -> reconciled — which is the approval/accountability spine (pre-approval, then a post-trip reconcile). It does NOT inline its visits: a visit is an ordinary Interaction (engagement.yaml) referencing the trip via `trip`. It is a context layer — it holds NO direct Gift foreign key; trip influence on dollars is a derived, windowed metric over the `Gift -> Opportunity/Proposal <- Interaction -> Trip` chain (ADR-0017). Operational logistics are out of scope (Document / Note / Extensible carry them); the only logistics fact stored here is cost.
22 fields in the beta explorer
Want the full picture?
Beta members get the complete explorer: the field-level reference for every entity above, role-based tours, the follow-a-gift walkthrough, and the from-your-CRM crosswalks. Free during the beta; every request is approved personally.
Read the schema, build to it
The standard, the crosswalks, and the metric definitions are open source. Explore them, open an issue, or build a conforming product.
References to Salesforce, Microsoft, the Fundraising Effectiveness Project, CASE, and other names are for interoperability and accuracy. Fundraising Commons is independent and not affiliated with or endorsed by any of them.