Appearance
For a UK or European repository the default is ISAD(G); for a US repository the default is DACS. Choose by jurisdiction and existing catalogue conventions first, then by how much formatting guidance you actually want — DACS prescribes name and date syntax, ISAD(G) deliberately does not. If you are starting fresh and want rules you can apply without writing a local manual, lean DACS; if you must interoperate with European union catalogues or already have ISAD(G) records, stay there.
What is the real difference between ISAD(G) and DACS?
ISAD(G) (General International Standard Archival Description, 2nd ed., 2000) is a framework of 26 elements grouped into seven areas. It tells you what to record but is almost silent on how to phrase it. DACS (Describing Archives: A Content Standard, currently the 2nd edition with ongoing TS-DACS revisions) is a true content standard: it specifies the rules of formulation — how to construct a title, how to express dates, how to record extent.
The other structural difference matters daily. ISAD(G) Rule 2.4 expects you to avoid repeating information given at a higher level, but in practice many ISAD(G) catalogues still restate it. DACS makes non-repetition explicit and pairs each element with a "single-level minimum" and "multilevel" requirement.
Which mandatory elements must I always supply?
Both standards converge on a small mandatory core. The table shows where they line up.
| Information | ISAD(G) mandatory | DACS single-level minimum |
|---|---|---|
| Reference code / identifier | Yes (3.1.1) | Yes (2.1) |
| Title | Yes (3.1.2) | Yes (2.3) |
| Date(s) | Yes (3.1.3) | Yes (2.4) |
| Extent | Yes (3.1.5) | Yes (2.5) |
| Creator | Yes (3.2.1) | Yes (2.6) |
| Level of description | Yes (3.1.4) | Implicit via multilevel rules |
If you build every record to satisfy this column, you are interoperable in both worlds. The divergence appears in the optional and conditional elements, and in syntax.
How do I decide for a specific project?
Work through these in order:
- Jurisdiction and funder. UK Archives Hub and European aggregators expect ISAD(G)-shaped data. US aggregators (and SNAC) expect DACS.
- Existing catalogue. Do not re-standardise 40 years of finding aids on a whim. Match what your back-catalogue already uses.
- Encoding target. Both crosswalk to EAD3, but DACS publishes an explicit element-to-EAD-and-MARC mapping, which saves work if you also produce MARC records.
- Staff capacity. DACS' prescriptiveness reduces decisions per record — useful for volunteers and new staff.
text
if jurisdiction in {US}: use DACS
elif legacy_records == "ISADG": stay ISADG
elif need_strict_syntax: adopt DACS rules over an ISADG skeleton
else: use ISADGCan I run a hybrid sensibly?
Yes, and many institutions do. The common pattern is an ISAD(G) element skeleton with DACS rules of formulation borrowed for titles, dates and names. This gives you European interoperability and consistent syntax. Document the hybrid in a local descriptive standards manual so successors do not re-litigate every choice. Record the decision once, cite the relevant DACS chapter, and move on.
What pitfalls trip people up?
- Re-keying inherited context at item level, inflating records and creating maintenance debt. Honour non-repetition.
- Mixing date conventions mid-collection (e.g.
1923vs[c.1923]) because ISAD(G) left it open. Pick a DACS-style rule and enforce it. - Treating DACS as US-only. Its content rules are perfectly usable on a UK base; only its access-point and authority conventions are notably North-American.
- Assuming the software decides. AtoM, Access to Memory and CALM all let you choose the template; the standard is your decision, not the tool's.
Key Takeaways
- Default to ISAD(G) in the UK/EU and DACS in the US; jurisdiction is the first filter.
- ISAD(G) says what to record; DACS says what and how — borrow DACS syntax if you want fewer per-record decisions.
- The mandatory core (reference, title, date, extent, creator) is nearly identical, so dual compliance is achievable.
- Honour non-repetition of inherited information; it is explicit in DACS and intended in ISAD(G).
- A documented hybrid (ISAD(G) skeleton + DACS rules) is a legitimate, common choice.
- Match your legacy catalogue before chasing a "purer" standard.
Frequently Asked Questions
Is DACS just a US version of ISAD(G)?
Not exactly. DACS is content-standard-only and was derived from ISAD(G) and APPM, but it adds explicit single-level and multilevel rules, maps elements to MARC and EAD, and drops the requirement to repeat inherited information at every level.
Can I be compliant with both standards at once?
Largely yes. DACS' single-level minimum maps cleanly onto ISAD(G)'s mandatory elements, so a record built to DACS will usually satisfy ISAD(G). The friction is mostly in terminology and in DACS' non-repetition rule.
Which standard does AtoM use by default?
AtoM ships templates for ISAD(G), DACS, RAD and others. You pick the template per repository or per description, so the software does not force the choice for you.
Does ISAD(G) tell me how to format names and dates?
No. ISAD(G) defines what information to capture but is largely silent on syntax. DACS gives concrete formatting rules, which is why mixed institutions often borrow DACS' rules even on an ISAD(G) base.
Is ISAD(G) being replaced by RiC?
The ICA positions Records in Contexts as the successor framework, but ISAD(G) remains the working standard in most catalogues today. Treat RiC as a direction of travel, not an immediate switch.
What about RAD or PPGM — should I consider those?
If you are in Canada use RAD, and for some manuscript traditions PPGM-style rules apply. For most UK/European institutions the real choice is ISAD(G), and for US institutions it is DACS.