URL to get this record's issuer information.

ID of the associated issuer for this record.

The Category is a direct reference to the parent_category found within the Authority Document List. Within this Issuers list, the Category starts there, while we allow end users to provide additional category suggestions in order to grow the list.

We humans have to use numbers. However, when entering numbers, we humans also have a tendency to screw up the entry or copying of those numbers. A Dutch mathematician named Jacobus Verhoeff conducted a study of 12,000 numerical errors J. Verhoeff, Error Detecting Decimal Codes, Mathematical Centre Tract 29, The Mathematical Centre, Amsterdam, 1969, cited in Wagner and Putter, "Error Detecting Decimal Digits", CACM, Vol 32, No. 1 (January 1989), pp. 106-110. and from that, proposed a check digit calculation scheme http://www.augustana.ab.ca/~mohrj/algorithms/checkdigit.html#verhoeff that catches all single errors as well as all adjacent transpositions and most other errors.

To ensure that the IDs assigned by the system have integrity during input as well as distribution while being transferred into various formats (such as Excel, Word, Text, XML), each ID will also have its own checksum value stored in a checksum field.

Currently, the methodology for creating and verifying the checksum follows the Verhoeff calculation format.

The CheckDigit is created along with the record's ID as a calculation by the UCF database system. As such, once assigned it should never change because the ID will never change. A sample calculation format is shown in the use case scenarios.

Date_Added is a date stamp for when the record was created.

This element is created when the record is entered into the UCF’s Master Content database and not the working database. We chose this method because the UCF team’s editorial process is a fluid one which allows, during the editing process, for records to be added, moved, deleted, or even “un-deleted” fluidly until the lock-date that ends the editorial process. Once the lock-date has been reached, all of the records are then finalized from the “working” list and uploaded as a batch to the Master Content database, which also triggers the change log process. Therefore, it is common to see all new records for any given quarter being added on the same date.

Because the Date Added element is controlled post-editorial process, the UCF database system manages everything automatically.

Date_Modified is a date stamp for when the record was modified. We use this as a key field for tracking all roll forward and roll backward field calculations. The initial date reflects the date the authority document was added to the database.

This element is created and updated when the record is entered into the UCF’s Master Content database and not the working database. We chose this method because the UCF team’s editorial process is a fluid one which allows, during the editing process, for records to be added, moved, deleted, or even “un-deleted” fluidly until the lock-date that ends the editorial process. Once the lock-date has been reached, all of the records are then finalized from the “working” list and uploaded as a batch to the Master Content database, which also triggers the change log process, which relies on this field to trigger that a change has taken place in the record. Therefore, it is common to see all new records for any given quarter being “modified” on the same date, and all modifications for the quarter to happen on the same date as well.

We have heard from multiple XML licensees that they would rather have the exact date and time that the record was modified instead of the batch upload date. That isn’t possible, given that all of the XML licensees also want us to produce a compact and digestible change log. A change log based upon the exact date of modification would have already produced several instances with over ten changes for certain records. Changes that were of no consequence to either the XML licensee or an end user, because those changes were simply a part of our internal editorial process. Therefore, to save processing time on the change log and to shorten the length (of the already very heavy) change log, we made the strategic decision to limit both date modified and date created to be the batch upload dates.

Because the Date Added element is controlled post-editorial process, the UCF database system manages everything automatically.

If a record in the UCF needs to be deprecated, the record will not be deleted from the system. Instead, the record will be marked as deprecated (its "Live Status" field will be set to 0), and the Deprecated By field will be filled out with the ID(s) of the record(s) that took its place (if any).

Initially this element is blank and only a UCF editorial process can indicate a Deprecated By content change. That change is then reviewed by the editorial reviewer and editorial approver. If there are contents in this field, the Live Status field must be set to deprecated (0).

Deprecation notes are new to version 2.1 of the UCF, and we’ve done as good a job as possible back-filling them to ensure that we have covered our bases.

In a nutshell, when our mappers, reviewers, or approvers have made the decision to deprecate one of the records in the various XML tables, they will add their deprecation notes, their reasoning, to this field. There is no set format for what they are writing, so there aren’t any hard and fast editorial rules, other than something has to be added to the field during deprecation.

Within the Authority Document table, the document_type is based upon a choice of items listed in their legal hierarchical status, as defined within the document_type, documented below.

• Bill or Act

• Regulation or Statute

• Contractual Obligation

• Self-Regulatory Body Requirement

• Audit Guideline

• Safe Harbor

• International or National Standard

• Best Practice Guideline

• Organizational Directive

• Vendor Documentation

• Not Set

The document_type list uses this list as a starting point, but doesn’t limit the recordset to this list in order for the list to grow organically. Therefore, we’ve set this as a string instead of pre-defined list.

ID of the associated issuer.issuer top level for this record.

If the record is in a specific language, that’s what needs to be entered here. However, we are not using the name of the language, but rather the ISO 639-2 Codes for the Representation of Names of Languages reference. A complete and up-to-date reference can be found online at http://www.loc.gov/standards/iso639-2/php/code_changes.php. By default, all records are in English (code eng).

Because some of the records within the UCF are being provided by external sources, we now indicate this with a URI stored here. By default, the URI will point to Unified Compliance usage license information.

If the record is subject to external (outside of the UCF) usage terms, the URI will point you to those usage terms.

This is either a 1 or a 0. It indicates whether the record is live within the database, or should be redacted.

Because the UCF™ treats every ID as both unique and persistent, we never delete an ID once used, nor do we re-use the ID. Therefore, if we have to redact a record, we merely mark the Live Status as moving from 1 (live) to 0 (redacted).

All records are initially created and marked by the system as Live (1). There are certain scripts that the UCF’s database team will run to ensure that two instances of automated deprecation takes place:

1. If an Authority Document has been deprecated, all of its citations will be deprecated.

2. If a control has no citations pointing to it, the control in question will be deprecated.

Other than the instances noted above, records must be deprecated as an editorial process and approved by both the editorial reviewer and the editorial approver. When the Live Status is set to deprecated (0), there might also be a corresponding setting for the Deprecated By element, but this is not mandatory.

An issuer is the harmonized title the UCF team has given all those who either publish or promulgate authority documents. Technically, a publisher is a firm in the business of issuing printed matter for sale or distribution. However, when it comes to laws, the correct term is promulgator. A promulgator is the legal body that announces a law as a way of putting it into execution. This is distinct and different from a law’s publishing office that prints and distributes the law. Sometimes the promulgator will have a domain under which to find their authority documents and sometimes they won’t. Therefore, we use the harmonized term of issuer to cover authors, publishers, and promulgators.

The issuer’s name might be a source of ambiguity because there are many ways to express the names of companies and other organizations. Therefore, our determination is the name used for the issuer should stem from the highest organization-specific label of the issuing organization's fully qualified domain name (FQDN) and URL directory where the document is made available. Even if the domain name is different from the organization’s name, your organization must use the domain name for the Issuer Name.

This is the subdirectory within the Issuer's website wherein the Authority Documents have been found.

The date and time the record was created.

The date and time the record was last updated.

This is the Unique Resource Locator of the issuing organization in fully qualified domain name (FQDN) format – as well as the top level directory of the issuer if the issuer does not have its own domain name.