Krav nr.	Kravgruppe	Beskrivelse	Type	Merknad
2.1	Krav	For at en systemløsning skal være i overensstemmelse med Noark 5, må det være mulig å lage en avbildning av systemets fysiske datamodell mot standardens logiske datamodell, slik denne er beskrevet i Vedlegg 2: *Metadata gruppert på objekter*	O	Kan gjøres i forbindelse med systemdesign, eller i ettertid for system som allerede er utviklet
2.2	Krav	Det skal være mulig å opprette, lese, endre og slette metadata og utvalg av metadata i henhold til metadatabeskrivelsene i Vedlegg 1: *Metadatakatalog*, knyttet til arkivenheter og andre objekter i slik de er beskrevet i Vedlegg 2: *Metadata gruppert på objekter*	O	
2.3	Krav	All opprettelse, lesing, endring og sletting av metadata og utvalg av metadata på arkivenheter og andre objekter skal logges i henhold til Vedlegg 3: *Logging av endringer*	O	
2.4	Krav	"Arkivdokumenter skal inngå i en arkivstruktur som minst inneholder følgende arkivenheter:

arkiv, arkivdel, registrering, dokumentbeskrivelse og dokumentobjekt."	O	
2.5	Krav	"Journalføringspliktige saksdokumenter skal inngå i en arkivstruktur som minst skal inneholde følgende arkivenheter:

arkiv, arkivdel, klassifikasjonssystem, klasse, mappe, registrering, dokumentbeskrivelse og dokumentobjekt."	O	Denne arkivstrukturen omtales som sakarkiv
2.6	Krav	For fysiske arkiv kan dokumentobjekt utgå	V	
2.7	Krav	Alle arkivenheter skal kunne identifiseres entydig innenfor et arkiv.	O	
2.8	Krav	Det skal være mulig å avslutte arkivenheter.	O	
2.9	Krav	Det skal ikke være mulig å legge til flere underliggende arkivenheter dersom en arkivenhet er avsluttet.	O	
2.10	Krav	Det skal ikke være mulig å slette arkivenheter som har aktive eller avsluttede underliggende arkivenheter.	O	
2.11	Krav	Det bør være mulig å slette arkivenheter som ikke har aktive eller avsluttede underliggende arkivenheter.	V	
2.12	Krav	Det bør være mulig å endre en arkivenhets tilknytning til overordnet arkivenhet	V	
2.13	Krav	Det skal ikke være mulig å endre en arkivenhets tilknytning til overordnet arkivenhet dersom den har koblinger til andre arkivenheter som brytes ved endringen. Dersom dette forsøkes skal brukeren få melding om hvilke koblinger som sperrer mot endringen.	B	Obligatorisk dersom det er mulig å endre arkivenheters tilknytning til overordnet arkivenhet
2.14	Krav	"Arkivenhetene mappe og registrering skal kunne være av forskjellig type.

Dette er i Vedlegg 2 *Metadata gruppert på objekter* løst gjennom spesialisering, ved at spesialiseringen har egne metadata i tillegg til arkivenheten"	O	
2.15	Krav	Journalføringspliktige saksdokumenter skal registreres som registreringstype journalpost i en mappe av typen saksmappe	B	Obligatorisk for løsninger med journalføring
2.16	Krav	Det bør være mulig for spesielt autoriserte brukere å opprette egne spesialiseringer av mappe og registrering, i tillegg til spesialiseringene som er definert i Vedlegg 2: *Metadata gruppert på objekter*.	V	
2.17	Krav	Det bør være mulig å definere relevante tilleggsmetadata på alle arkivenheter og tilhørende objekt, utover det som er dokumentert i Vedlegg 2: *Metadata gruppert på objekter.*	V	
2.18	Krav	Arkivenheter på de øverste nivåene av arkivstrukturen (arkiv, underarkiv, arkivdel, klassifikasjonssystem og klasse) skal kun opprettes og endres av brukere som er spesielt autorisert for det.	O	
2.19	Krav	Systemløsningen skal legge til rette for forvaltning og vedlikehold av ett eller flere klassifikasjonssystem	B	Obligatorisk for sakarkiv
2.20	Krav	Dersom det benyttes flere klassifikasjonssystem for en arkivdel, skal ett av klassifikasjonssystemene defineres som primært klassifikasjonssystem som styrer arv av skjerming og bevaring og kassasjon.	B	Obligatorisk for sakarkiv
2.21	Krav	Det skal være mulig for spesielt autoriserte brukere å angi regler for når dokumentfiler skal konverteres til arkivformat	B	Obligatorisk ved arkivering av dokumentfiler
2.22	Krav	Det skal være mulig for autoriserte brukere å angi hvilke filformater som skal brukes som arkivformater for ulike typer dokumenter	B	Obligatorisk ved arkivering av dokumentfiler
2.23	Krav	Det skal ikke være mulig å slette den siste, endelige versjonen av et arkivert dokument	B	Obligatorisk ved arkivering av dokumentfiler
2.24	Krav	Det bør være mulig for spesielt autoriserte brukere å slette inaktive versjoner, varianter og formater av arkiverte dokumenter	V	
2.25	Krav	Sletting av inaktive versjoner, varianter og formater skal logges	B	Obligatorisk ved arkivering av dokumentfiler
2.26	Krav	Det skal være mulig å få en oversikt over hvilke filformater som er lagret i løsningen, inkludert hvilke mapper, registreringer og/eller dokumentbeskrivelser som inneholder dokumenter som ikke er lagret i arkivformat.	B	Obligatorisk ved arkivering av dokumentfiler
2.27	Krav	Det bør være mulig å kjøre teknisk test av filformater som er lagret i løsningen, for å avgjøre om de oppfyller krav til arkivformat	V	
3.1	Krav	Det skal finnes funksjonalitet for fangst av digitale dokumenter uavhengig av filformat, metoder for teknisk koding, kilder eller andre tekniske egenskaper.	O	
3.2	Krav	Ved fangst av dokumenter skal det være mulig å knytte obligatoriske metadata til dokumentet, enten ved at de følger dokumentet fra et produksjonssystem, eller ved at de registreres manuelt i etterkant.	O	
3.3	Krav	Dokumentfangsten skal skje på en slik måte at innholdsintegriteten blir opprettholdt for dokument og metadata.	O	
3.4	Krav	Ved fangst av tekstdokumenter bør løsningen sørge for at dokumentenes visuelle integritet blir oppretthold	V	
3.5	Krav	Ved fangst av bilde-, lyd- eller videofiler bør løsningen sørge for at opprettholdelse av dokumentenes lyd- og billedintegritet	V	
3.6	Krav	Etter fangst eller opprettelse av dokumenter skal løsningen legge til rette for kontrollmekanismer for endring av metadata og dokumenter i henhold til regler fastsatt av virksomheten, for eksempel at visse metadata ikke skal kunne endres etter gitte hendelser utført på en registrering eller en mappe.	O	
3.7	Krav	Ved fangst av dokumenter som består av flere komponenter (meldinger med vedlegg, innebygde objekt som video eller bilde, mv.), skal løsningen sørge for at dokumentene håndteres som en enhet, hvor dokumentenes indre struktur og relasjonen mellom komponentene opprettholdes	B	Obligatori sk for løsninger som håndterer sammensatte dokumenter
3.8	Krav	Ved fangst av dokumenter som har tilleggsmekanismer for verifikasjon av integritetssikring (digital signatur, sjekksum, mv.), skal løsningen kunne verifisere metoden for integritetssikring og ta vare på metadata om verifikasjonen.	O	
3.9	Krav	Løsningen bør legge til rette for fangst og bevaring av metadata om bruk av digital signatur (dato, tidsstempel, verifikasjon)	V	
3.10	Krav	Det bør være mulig å arkivere dokumenter i forskjellige versjoner, varianter og formater	V	
4.1	Krav	Løsningen skal sikre at dokumenter og tilhørende metadata er lagret bestandig og sikkert, og at de forblir tilgjengelig og kan hentes frem over tid, i tråd med definert bevaringstid	O	
4.2	Krav	Det bør være mulig å definere regler for at løsningen skal generere sjekksummer eller andre mekanismer for integritetskontroll på dokumentene i løsningen.	V	
4.3	Krav	Brukere som skal ha tilgang til arkivenheter, objekter og dokumenter i en Noark 5-løsning, skal identifiseres, autentiseres og autoriseres i tilstrekkelig grad før de blir gitt tilgang	O	En bruker kan være en person eller et system
4.4	Krav	Det bør være mulig å identifisere, autentisere og autorisere brukere via en ekstern katalog eller et eksternt system som definerer hvilke rettigheter brukeren skal ha	V	
4.5	Krav	Brukere bør kunne autoriseres på grunnlag av administrativ tilhørighet	V	
4.6	Krav	Løsningen skal kunne gjenkjenne hvilken administrativ sammenheng eller rolle brukeren har og opptrer i til enhver tid	O	
4.7	Krav	En bruker som ikke lenger skal ha tilgang til arkivenheter, objekter og dokumenter i en Noark 5-løsning, skal fortsatt være identifisert i løsningen, men med en status som indikerer at den er passiv, som hindrer brukeren i å få tilgang til løsningen	O	
4.8	Krav	Det skal finnes en oversikt over hvilket eller hvilke tidsrom hver bruker har vært aktiv	O	
4.9	Krav	Det bør være mulig å endre en brukers navn uten å endre brukerens identifikasjon i løsningen.	V	
4.10	Krav	All redigerings- og skrivetilgang i Noark 5-løsningen skal være basert på et “need to know” grunnprinsipp	O	
4.11	Krav	Et “need to protect” grunnprinsipp kan velges for lesetilganger	V	
4.12	Krav	Det skal ikke være mulig å opprette roller som opphever de generelle begrensninger som er definert i løsningen	O	
4.13	Krav	Ulike kombinasjoner av funksjonelle krav som stilles til brukerens autorisasjon bør kunne settes sammen til forskjellige funksjonelle roller, som uttrykker typiske stillingskategorier eller oppgaveporteføljer i virksomheten	V	
4.14	Krav	For hver funksjonell rolle bør det være mulig å definere et regelsett for prosessrelaterte rettigheter	V	
4.15	Krav	Det bør være mulig å definere eller avgrense en rolles nedslagsfelt, for eksempel til angitte arkivenheter med underliggende arkivenheter, angitte organisatoriske grenser, visse typer mapper eller registreringer, gitte skjermings- eller graderingskoder, egenskaper ved registrerte parter, eller andre definerte kriterier som finnes i løsningen.	V	
4.16	Krav	En bruker bør kunne ha ulike roller	V	
4.17	Krav	Innenfor hver av rollene som en bruker har, bør det kunne defineres en tilgangsprofil som utgjøres av rollens funksjonelle rettigheter i kombinasjon med nedslagsfeltet for rollen	V	
4.18	Krav	Det skal lagres informasjon om hvilke tilgangsrettigheter en bruker har hatt, og når de var gyldige	O	
4.19	Krav	Tilgangsrettigheter for en identifisert bruker skal kunne begrenses i tid, rettighetene må kunne gjelde fra dato til dato	O	
5.1	Krav	Noark 5-løsningen bør inneholde funksjonalitet som henter eller mottar dokumenter fra en angitt plassering eller et eksternt system eller en modul, og knytte disse til klasser, mapper, registreringer eller dokumentbeskrivelser.	V	
5.2	Krav	Noark 5-løsningen bør kunne hente eller motta metadata knyttet til alle dokumentene som overføres, automatisk. Det bør være mulig å overstyre dette ved manglede eller feil metadata.	V	
5.3	Krav	Ved import av dokumenter og metadata skal det være funksjonalitet for å validere metadata med tilhørende dokumenter automatisk, for å sikre opprettholdt dataintegritet.	B	Obligatorisk ved integrasjoner
5.4	Krav	Ved import skal det være mulig å importere logginformasjon om de importerte dokumentene, og logginformasjonen skal inngå i importen som eget (egne) dokument eller som virksomhetsspesifikke metadata.	B	Obligatorisk ved integrasjoner
5.5	Krav	Alle moduler eller systemer utenfor Noark 5-løsningen, som skal kommunisere med eller ha tilgang til objekter i Noark 5-løsningen, skal være identifisert og gjenkjennes av Noark 5-løsningen	B	Obligatorisk ved integrasjoner
5.6	Krav	En ekstern modul som ikke lenger skal ha tilgang til tjenester skal fortsatt være identifisert i Noark 5-løsningen, men med en status som indikerer at den er «passiv»	B	Obligatorisk ved integrasjoner
5.7	Krav	Det skal finnes en oversikt over hvilket eller hvilke tidsrom hver ekstern modul har vært aktiv	B	Obligatorisk ved integrasjoner
5.8	Krav	Det skal finnes en oversikt over hvilke arkivenheter med underliggende arkivenheter en ekstern modul har eller har hatt lesetilgang til	B	Obligatorisk ved integrasjoner
5.9	Krav	Det skal finnes en oversikt over hvilke arkivenheter med underliggende arkivenheter en ekstern modul har eller har hatt skrivetilgang til	B	Obligatorisk ved integrasjoner
5.10	Krav	For løsninger hvor Noark-kjernen skal ha en fullstendig integrasjon med fagsystemet bør Noark 5 tjenestegrensenitt brukes.	V	
6.1	Krav	Det skal være mulig å søke i og gjenfinne dokumenter og metadata i løsningen	O	
6.2	Krav	Det skal være mulig å søke i ulike kombinasjoner av metadata	O	
6.3	Krav	Løsningen skal sørge for at sikkerhet og tilgangsrestriksjoner blir ivaretatt, slik at kun autoriserte brukere får tilgang på informasjon i henhold til definerte tilgangsrettigheter	O	
6.4	Krav	Løsningen skal hente, vise og tilgjengeliggjøre dokumenter og metadata i anvendbare format	O	
6.5	Krav	Løsningen bør legge til rette for at dokumenter og metadata kan gjøres tilgjengelig for søk via eksterne tjenester, plattformer, nettverk eller samhandlingsløsninger.	V	
6.6	Krav	Løsningen bør legge til rette for at metadata og dokumenter som er godkjent for det, kan høstes av eller deles med eksterne tjenester og applikasjoner som åpne data.	V	
6.7	Krav	Løsningen skal støtte funksjoner som gjør det mulig å kopiere eller trekke ut dokumenter og metadata til bruk i andre løsninger i eller utenfor virksomheten i henhold til regler fastsatt av virksomheten	O	
6.8	Krav	Løsningen bør legge til rette for at det kan lages uttrekk av et utvalg dokumenter og metadata basert på definerte kriterier, hvor skjermet informasjon er fjernet eller skjult	V	
6.9	Krav	Det skal være mulig å hente ut en rapport kalt Løpende journal, som viser en kronologisk oversikt over alle journalførte dokumenter for hver dag. Rapporten skal kunne selekteres på grunnlag av journaldato, løpenummer (intervall), journalposttype og administrativ enhet. Det bør også være mulig å hente ut rapporten basert på andre kriterier.	B	Obligatorisk for arkiv med journalføringspliktige dokumenter
6.10	Krav	"Rapporten Løpende journal skal vise hvilken sak journalposten inngår i, med informasjon om:

- saksnummer,
- sakens tittel,
- administrativ enhet,
- saksansvarlig og
- hvilken arkivdel saken inngår i,

i tillegg til sakens klassifikasjon, samt at den skal vise opplysninger om journalpostens identifikasjon:

- journalpostens løpenummer i saken,
- journaldato,
- dokumentets dato,
- administrativ enhet,
- journalposttittel, samt
- korrespondansepartens navn og type,

i tillegg til opplysninger om eventuell tilgangsrestriksjon”"	B	Obligatorisk for arkiv med journalføringspliktige dokumenter
6.11	Krav	Det skal være mulig å hente ut en rapport kalt Offentlig journal, som er en versjon av Løpende journal hvor taushetsbelagte opplysninger enten er skjermet eller utelatt, og som kan tilgjengeliggjøres for allmennheten. Rapporten skal inneholde alle journalposttyper, og skal kunne selekteres på grunnlag av journaldato, administrativ enhet eller dato for når journalposten er offentlighetsvurdert. Det bør være mulig å hente ut en tilsvarende rapport basert på andre kriterier.	B	Obligatorisk for arkiv med journalføringspliktige dokumenter
6.12	Krav	"Rapporten Offentlig journal skal vise hvilken sak journalpostene inngår i, med informasjon om:

- saksnummer
- sakens offentlige tittel,

i tillegg til sakens klassifikasjon, samt at den skal vise opplysninger om journalpostens identifikasjon, som:

- journalpostens løpenummer i saken,
- journaldato,
- dokumentets dato,
- administrativ enhet,
- dokumentets offentlige tittel, samt
- korrespondansepartens navn (med mindre navnet skal skjermes) og korrespondanseparttype (avsender eller mottaker, mv.),
- opplysninger om innkomne dokumenters behandlingsoppfølging,

i tillegg til opplysninger om eventuell hjemmel for skjerming av journalopplysninger

Det er tillatt å tilgjengeliggjøre andre opplysninger om dokumentene”"	B	Obligatorisk for arkiv med journalføringspliktige dokumenter
6.13	Krav	For en part som krever innsyn etter forvaltningsloven skal det kunne gis utskrift av alle metadata og dokumenter i den bestemte saken. Opplysninger skal vises selv om de er påført tilgangskoder	B	Obligatorisk for arkiv med partsinformasjon etter forvaltningsloven
6.14	Krav	For en person som krever innsyn etter personopplysningsloven skal det kunne gis utskrift av alle metadata om de saker hvor vedkommende er part i saken, og de registreringer med tilhørende dokumenter og merknader der vedkommende selv er avsender eller mottaker. Eventuelle skjermede opplysninger om andre parter i saken skal skjermes i utskriften	B	Obligatorisk for arkiv med personopplysninger
7.1	Krav	Det bør være mulig å knytte arbeidsflyter til registreringer, for eksempel godkjenningsflyter på egenproduserte registreringer.	V	
7.2	Krav	Metadata om arbeidsflyter skal normalt bevares	B	Obligatorisk ved bruk av arbeidsflyter
7.3	Krav	Det bør være mulig å knytte definerte oppgaver til visse typer registreringer, for eksempel at innkomne dokumenter eller visse typer organinterne dokumenter skal settes i restanse.	V	
7.4	Krav	Det bør være mulig å få en oversikt over restanser og andre ventende oppgaver i løsningen, for eksempel en restanseliste eller en forfallsliste for enkelte brukere eller enheter	V	
7.5	Krav	Det bør finnes funksjoner får å markere en oppgave som utført, for eksempel ved å avskrive en restanse	V	
7.6	Krav	Metadata om gjennomføring av oppgaver, for eksempel avskrivning av restanse, skal normalt bevares	B	Obligatorisk ved funksjoner for oppgaver eller restanseoppfølging
7.7	Krav	Det bør være mulig å knytte merknader, nøkkelord og referanser til arkivenheter	V	
7.8	Krav	Det bør være mulig å opprette en presedens knyttet til en sak eller en journalpost	V	
7.9	Krav	Det bør være mulig å opprette et register over hvilke verdier man skal kunne velge presedenshjemmel fra	V	
7.10	Krav	Det skal ikke være mulig å slette eller kassere en presedens, selv om presedensen er foreldet, eller klassen som presedensen tilhører skal kasseres	B	Obligatorisk ved registrering av presedens
8.1	Krav	"Løsningen skal ha funksjoner for å registrere metadata om bevaringstid og bevarings- eller kassasjonsvedtak på arkivenheter.

Vedtaket fastsetter hva som skal skje med dokumentene knyttet til arkivenheten når bevaringstiden opphører. Kassasjonsvedtaket kan si at dokumentene enten skal bevares, kasseres eller at de skal vurderes senere."	O	
8.2	Krav	Det bør være mulig å definere regler som automatisk knytter bevaringstid og kassasjonsvedtak til en type arkivenhet, en bestemt spesialisering av en arkivenhet, eller en bestemt type av en spesialisering av en arkivenhet.	V	
8.3	Krav	Bevaringstid og kassasjonskode skal arves til underliggende arkivenheter ned til dokumentbeskrivelse. Det skal være mulig å overstyre arv.	O	
8.4	Krav	"Løsningen bør legge til rette for at autoriserte brukere kan definere regler for fastsetting av kassasjonsdato på grunnlag av oppbevaringstid. For eksempel kan oppbevaringstid beregnes fra:

- Dato for opprettelse av arkivenhet
- Avslutning av arkivenhet
- Dato for siste bruk av arkivenhet
- Dato for definerte hendelser, som

klientens fødsel eller dødsfall, ødeleggelse av et objekt (f.eks. bygning, skip), eller andre hendelser som kan forutsette virksomhetsspesifikt datofelt"	V	
8.5	Krav	Løsningen bør legge til rette for at definerte brukere får varsling når oppbevaringstiden nærmer seg, med oversikt over arkivenheter som skal kasseres eller vurderes senere.	V	
8.6	Krav	Løsningen skal ha funksjoner for å gjennomføre kassasjon av de dokumenter som har passert kassasjonsdato. Det skal være mulig å velge delmengder av dokumenter når kassasjon skal gjennomføres.	O	
8.7	Krav	Bare autoriserte brukere skal kunne gjennomføre kassasjon.	O	
8.8	Krav	Kassasjon innebærer sletting av arkivenheten dokumentobjekt. I tillegg skal dokumentfila som arkivenheten har referanse til slettes, med mindre den er knyttet til andre arkivenheter som skal bevares. Metadata på overliggende arkivenheter skal i som hovedregel bevares. Arkivenheten dokumentbeskrivelse skal ha metadata om utført kassasjon.	O	
8.9	Krav	"Det skal være mulig å lage en kassasjonsliste på grunnlag av kassasjonsdato, kassasjonsvedtak og administrativ enhet.

Kassasjonslisten skal gi en oversikt over arkivenheter, med identifikasjon og tittel for arkivenheten, administrativ tilhørighet og eventuell klassifikasjon, samt kassasjonsvedtak og kassasjonsdato."	O	
8.10	Krav	Løsningen skal legge til rette for at det er mulig å sette kontrollerte tidsskiller i arkiv. Det innebærer at autoriserte brukere kan definere regler for hvordan mapper og registreringer skal opprettes og avsluttes i overgangen mellom to arkivperioder. Avsluttede og uaktuelle mapper og registreringer skal kunne skilles ut fra aktive til avsluttede arkivdeler, slik at de kan klargjøres for eksport, enten som migrering, overføring, avlevering eller andre former for datauttrekk.	O	
8.11	Krav	"Løsningen skal legge til rette for eksport av metadata med tilhørende dokumenter for:

- migrering til andre løsninger for videre forvaltning av dokumentasjonen internt i virksomheten,
- overføring til løsninger i andre virksomheter som skal overta dokumentasjonen,
- datauttrekk i systemuavhengige format som støtter bevaring utover systemets levetid, for eksempel basert på avleveringsformatet."	O	
8.12	Krav	"Løsningen skal sikre at et datauttrekk for eksport:

- er komplett, dvs. inneholder alle arkivenheter og dokumenter som skal være med,
- inneholder alle obligatoriske og andre relevante metadata for arkivenhetene, inkludert metadata om godkjenningsflyter eller arbeidsflyter, samt virksomhetsspesifikke metadata ved behov
- inneholder arkivenhetenes loggemetadata og løsningens endringslogg."	O	
8.13	Krav	"Datauttrekk for eksport skal skje på en slik måte at

- innhold og struktur på dokumenter og metadata ikke medfører utilsiktet svekkelse av dokumentasjonens tilsiktede egenskaper, inkludert dens dokumentasjons- og informasjonsverdi,
- koblingen mellom dokumenter og metadata opprettholdes, og at
- koblinger opprettholdes mellom ulike komponenter i et dokument, mellom ulike dokumenter, og mellom ulike sammenstillinger av dokumenter, slik at logisk struktur kan gjenopprettes i mottakende løsning"	O	
8.14	Krav	Det skal være mulig å teste og verifisere at eksporten ikke har svekket dokumentenes og metadataenes integritet, og at datauttrekket ikke mangler obligatoriske og andre nødvendige metadata i henhold til standarden og/eller øvrige juridiske krav og behov.	O	
8.15	Krav	"Et datauttrekk som skal inngå i en avleveringspakke kalles et arkivuttrekk, og skal inneholde følgende filer:

- addml.xml (dokumentasjon av innholdet i arkivuttrekket)
- arkivstruktur.xml (metadata om dokumentene)
- endringslogg.xml (logging av endrede metadata)

Dersom avleveringspakken inneholder arkivuttrekk med journalføringspliktig informasjon, skal den i tillegg inneholde følgende filer:

- loependeJournal.xml
- offentligJournal.xml

XML-skjemaene til alle XML-filer i avleveringspakken skal også være inkludert. Dokumentene skal ligge i en underkatalog kalt DOKUMENT. Denne katalogen kan struktureres i nye underkataloger etter fritt valg."	O	
8.16	Krav	"XML-filene i arkivuttrekket skal valideres mot medfølgende XML-skjema på følgende måte:

- addml.xml valideres mot addml.xsd
- arkivstruktur.xml valideres mot arkivstruktur.xsd og metadatakatalog.xsd
- endringslogg.xml valideres mot endringslogg.xsd og metadatakatalog.xsd
- loependeJournal.xml valideres mot loependeJournal.xsd og metadatakatalog.xsd
- offentligJournal.xml valideres mot offentligJournal.xsd og metadatakatalog.xsd

For virksomhetsspesifikke metadata skal det medfølge egne XML-skjemaer."	O	
8.17	Krav	XML-skjemaene skal følge XML skjema-standarden XML Schema 1.0.	O	
8.18	Krav	Et arkivuttrekk skal omfatte en avtalt arkivperiode, og bestå av innholdet i en eller flere arkivdeler og alle underliggende arkivenheter	O	
8.19	Krav	Alle metadataelementer som er merket med “A” i kolonnen “Avl.” i Vedlegg 2 Metadata gruppert på objekter skal være med i arkivuttrekket, såfremt de er tilordnet verdier.	O	
8.20	Krav	Metadataelementer som ikke har verdi, skal ikke være med i uttrekket. Det skal ikke forekomme tomme elementer med kun start- og slutt-tagg, og det skal ikke legges inn dummyverdier.	O	
8.21	Krav	Dokumentfilene i arkivuttrekket skal være i avtalt filformat.	O	
8.22	Krav	"For arkivuttrekk fra Noark 5-løsninger skal addml.xml inneholde (med navn i addml.xml i parentes):

- Arkivskapernavn (recordCreator)
- Navn på systemet/løsningen (systemName)
- Navn på arkivet (Archive)
- Start- og sluttdato for arkivuttrekket (archivalPeriod – startDate og archivalPeriod endDate)
- Hvilken type periodisering som er utført i forrige periode og denne periode (periode – inngaaendeSkille og periode – utgaaendeSkille)
- Opplysning om det finnes skjermet informasjon i uttrekket (inneholderSkjermetInformasjon)
- Opplysning om uttrekket omfatter dokumenter som er kassert (omfatterDokumenterSomErKassert)
- Opplysning om uttrekket inneholder dokumenter som skal kasseres på et senere tidspunkt (inneholderDokumenterSomSkalKasseres)
- Opplysning om det finnes virksomhetsspesifikke metadata i arkivstruktur.xml (inneholderVirksomhetsspesifikkeMetadata)
- Antall mapper i arkivstruktur.xml (numberOfOccurrences – mappe)
- Antall registreringer i arkivstruktur.xml, loependeJournal.xml og offentligJournal.xml (numberOfOccurrences – registrering)
- Antall dokumentfiler i uttrekket (antallDokumentfiler)
- Sjekksummer for alle XML-filer og XML-skjemaer i arkivuttrekket, unnttatt addml.xml og addml.xsd (checksum)"	O