######### Partnership in Tomorrow Meeting Minutes

######### CASS/MASS Cycle 2002-2003 (2-03), August 13, 2001

The National Customer Support Center hosted the 11^th^ annual
"Partnership in Tomorrow" meeting, with industry representatives in
attendance, held in Memphis, Tennessee.

The following minutes constitute a record of the discussions held during
the "Partnership in Tomorrow" meeting for the CASS/MASS cycle 2002-2003
(2-03). In addition, these minutes may contain other requirements not
specifically discussed during this meeting and may also be considered as
requirements for address matching software for CASS cycle 2-03. These
minutes are subject to change. Any changes will be published prior to
November 15, 2001 for the 2-03 CASS Cycle. Unless otherwise modified,
the United States Postal Service (USPS) will automatically consider the
concurrence of the software and multiline industry. Developers and
manufacturers may submit written comments to the Certification
Department for receipt by close of business November 1, 2001.

General Discussion Items [2](#general-discussion-items)

Previous Cycle Review [2](#previous-cycle-review)

CASS/MASS 1-02 Significant Milestones
[2](#cassmass-1-02-significant-milestones)

CASS Message Board [2](#cass-message-board)

Analysis Tools via the Web [2](#analysis-tools-via-the-web)

Web Based Ordering System [3](#web-based-ordering-system)

Fee-Based Certification [3](#fee-based-certification)

Pass/Fail Policy Revisited [4](#passfail-policy-revisited)

Status of Progressive Error Inclusion (PEI)
[4](#status-of-progressive-error-inclusion-pei)

Revised PS Form 3553 [5](#revised-ps-form-3553)

Revised Platform Testing Policy [5](#revised-platform-testing-policy)

Policy Revision (Multiple Secondary Components)
[5](#policy-revision-multiple-secondary-components)

Ranged Alias Questions [6](#ranged-alias-questions)

Record Type [6](#record-type)

Multiple-Field Addresses with Split Indicia
[7](#multiple-field-addresses-with-split-indicia)

Restrictions on Unique Address Matching
[7](#restrictions-on-unique-address-matching)

Grading Issues [8](#grading-issues)

Delivery Point Validation (DPV) [8](#delivery-point-validation-dpv)

Multiple Response Handling [8](#multiple-response-handling)

DPV Return Codes [12](#dpv-return-codes)

DPV Secondary Information [12](#dpv-secondary-information)

Early Warning System (EWS) [13](#early-warning-system-ews)

Chasing the Base (or Hi-Rise Alternate Coding Rules)
[14](#chasing-the-base-or-hi-rise-alternate-coding-rules)

Recombination [14](#recombination)

Preferred Last Line City State Key
[15](#preferred-last-line-city-state-key)

Record Type Code [16](#record-type-code)

MASS Issues [16](#mass-issues)

Machine Identifier Proposal [16](#machine-identifier-proposal)

Grading Issues [17](#grading-issues-1)

Misread/Miscodes [17](#misreadmiscodes)

Reject Allowance [17](#reject-allowance)

Trailing Alpha File [17](#trailing-alpha-file)

Pound Signs and New Test/Audit Envelopes
[17](#pound-signs-and-new-testaudit-envelopes)

Handwriting Technologies [18](#handwriting-technologies)

Recombination for MASS [18](#recombination-for-mass)

Concatenated Last Lines [19](#concatenated-last-lines)

### General Discussion Items

# Previous Cycle Review

The past CASS cycle was reviewed to determine if any adjustment would
need to be made in the upcoming cycle schedule. Significant milestones
of the cycle are contained in the event schedule shown below.
Particularly noteworthy is that no extension to the cycle was needed to
accommodate end users.

##### 

+-----------------------------------------------------------------------+
| # CASS/MASS 1-02 Significant Milestones                               |
+-----------------------------------------------------------------------+
| Annual Meeting Held Aug 23-24, 00                                     |
+-----------------------------------------------------------------------+
| Stage 1 File Released 10/15/00                                        |
+-----------------------------------------------------------------------+
| Stage 2 File Available 12/15/00                                       |
+-----------------------------------------------------------------------+
| First CASS-Certified Product 01/29/01                                 |
+-----------------------------------------------------------------------+
| MASS Test Decks Available 03/15/01                                    |
+-----------------------------------------------------------------------+
| First MASS Manufacturer Certified 04/09/01                            |
+-----------------------------------------------------------------------+

# CASS Message Board

We have good news and bad news regarding the Message Board. First the
good news---we plan to increase the number of communications via the
Message Board during the next cycle. This gives CASS a great venue to
issue notices to the software community regarding stage files and other
address matching issues. In addition, it reduces our workload associated
with responding to redundant technical questions previously answered.
The bad news is the recent technical problems we have experienced with
the board itself --- it completely crashed. We are working to have all
previous users reestablished, add new customers, and notify participants
that it is up and running again. Please be patient, we will let you know
when the "Board is Back!" If you attended any of our meetings and
provided us with your email address, we will provide you with a login ID
and password for board access. If you haven't attended our meetings in
the past, you may send an email to Deborah Sanders at
<dsander3@email.usps.gov> to become a member of our Message Board
community.

# Analysis Tools via the Web

We have received final approval to distribute our internal address
matching lookup engine---Z4T (Windows) to CASS software developers. We
previously announced this item in earlier meeting minutes.

Effective November 1, 2001, the developer analysis version of the USPS
address-matching system will be distributed monthly to CASS certified
vendors who request it. Z4T uses the same source code as the lookup
engine located at www.usps.com/ ncsc/lookups/lookup_zip+4.html. However,
this lookup provides more information, allowing the user to diagnose
each matched/no-matched input address. It serves as our benchmark for
reconciling address issues and is used extensively by departmental
technical support staff in evaluating your error reports. If you would
like to be on the distribution list for this software, please contact
Deborah Sanders via email at the address noted above.

# Web Based Ordering System

We are continuing to work on our web ordering system, but we have had to
drop this project to a lower priority to ensure we met our core
deliverables, as previously noted. We definitely see the benefits of a
web-based ordering system, especially for our customers who depend on
the fax to send in order information. As some of you may have
experienced, this is not the most reliable means of sending an
application to our office. At this time, we have not decided when the
web ordering form will be available. We will post any breakthroughs via
the Message Board, when it's up, and email you otherwise.

#### DMM A950 Database Use Policy Review

In past discussions, we explored reducing the monthly product database
use dates from the current 105 days to 90 days. This was driven by our
overall goal to improve address quality. Also under consideration was
changing the 180 valid start date on the PS Form 3553 from the variable
"Date List Processed" to the fixed "Date of the Product/Database", which
would also significantly reduce the period for which any Address
Information System (AIS) database could be used. We are now reviewing
this position and informing the development community that we will
continue to pursue the objective of reducing the use dates for some of
our AIS products, while also considering eliminating bi-monthly product
frequency altogether. Your comments on this issue are welcome and you
may send them to bkinser@email.usps.gov.

### 

#### CASS/MASS 2-03 Cycle Milestones

As discussed during our meeting, the cycle schedule essentially remains
intact without change, however a few minor adjustments are noteworthy.
MASS test decks will be available 15 days earlier, and CASS will
terminate current cycle testing (1-02) April 1, 2002. This schedule
appears to work for everyone and we anticipate meeting our timelines as
published.

  -----------------------------------------------------------------------
  **CASS/MASS 2--03 Cycle Milestones**

  Full CASS/MASS Meeting 08/13/01

  Meeting Minutes Release 10/01/01

  Stage 1 File Release 10/15/01

  Stage 2 File Available 12/15/01

  MASS Test Decks Available 03/01/02

  1- 02 Testing Terminates 04/01/02

  Cycle 2 - 03 Compliance Date 08/01/02
  -----------------------------------------------------------------------

# Fee-Based Certification

# 

Fees for CASS and MASS certification were put in effect for cycle 1-02.
These charges were established to cover costs of developing and issuing
our testing material and administering the overall CASS and MASS
program. The impact of fees was clear and compelling. They directly and
positively attributed to one of the most orderly cycles in history. By
all counts, fee-based certification definitely improves the management
of the cycle from any measurable perspective.

As a result of fees in-place, our ability to provide customer service
improved; we were able to turn electronic and MASS tests decks around
much faster, and more importantly, we avoided the massive "crunch"
period normally associated with the months of June and July. Moreover,
no blanket cycle extension was even considered, let alone requested from
any customer. The table below clearly shows the impact of fees and their
ability to influence the production process. As you may expect, we plan
to continue this practice of fee-for-service for the foreseeable future.

+------------+-------+---+-----+-------+-------+-------+-------+-------+
| ###        |       |   |     |       |       |       |       |       |
| ###### Fee |       |   |     |       |       |       |       |       |
| -Based Cer |       |   |     |       |       |       |       |       |
| tification |       |   |     |       |       |       |       |       |
+------------+-------+---+-----+-------+-------+-------+-------+-------+
|            | De    |   | Feb | March | Apr   | May   | June  | July  |
|            | c/Jan |   |     |       |       |       |       |       |
+------------+-------+---+-----+-------+-------+-------+-------+-------+
| CASS Fees  | \$200 |   | \$  | \$200 | \$500 | \$500 | \$500 | \$500 |
|            |       |   | 200 |       |       |       |       |       |
+------------+-------+---+-----+-------+-------+-------+-------+-------+
| MASS       | \$0   |   | \$0 | \$300 | \$500 | \     | \     | \     |
|            |       |   |     |       |       | $1000 | $1000 | $1500 |
| Ma         |       |   |     |       |       |       |       |       |
| nufacturer |       |   |     |       |       |       |       |       |
+------------+-------+---+-----+-------+-------+-------+-------+-------+
| MASS       | \$0   |   | \$0 | \$0   | \$0   | \$0   | \$    | \$500 |
|            |       |   |     |       |       |       | 400\* |       |
| End User   |       |   |     |       |       |       |       |       |
+------------+-------+---+-----+-------+-------+-------+-------+-------+
| Number of  |       |   |     |       |       |       |       |       |
| Tests      |       |   |     |       |       |       |       |       |
| Processed  |       |   |     |       |       |       |       |       |
| by Month   |       |   |     |       |       |       |       |       |
| by Product |       |   |     |       |       |       |       |       |
+------------+-------+---+-----+-------+-------+-------+-------+-------+
| CASS 1-02  |       | 2 |     | 55    | 143   | 84    | 96    | 108   |
|            |       | 4 |     |       |       |       |       |       |
+------------+-------+---+-----+-------+-------+-------+-------+-------+
| CASS 0-01  |       | 1 |     | 59    | 32    | 60    | 122   | 119   |
|            |       | 7 |     |       |       |       |       |       |
+------------+-------+---+-----+-------+-------+-------+-------+-------+
| MASS 1-02  |       | 0 |     | 25    | 414   | 603   | 322   | 190   |
+------------+-------+---+-----+-------+-------+-------+-------+-------+
| MASS 0-01  |       | 0 |     | 0     | 9     | 275   | 666   | 616   |
+------------+-------+---+-----+-------+-------+-------+-------+-------+

\*Note: Reduced to \$200 for first15 days of this month for cycle "F"

# Pass/Fail Policy Revisited

In responding to the industry's concerns, we are relaxing the
restrictions on the disclosure of percentage scores associated with the
awarding of certification. As you may recall, these restrictions were
deemed necessary due to a few recalcitrant manufacturers who used their
CASS scores to differentiate their product offering through various
advertisements. As you would expect, we maintain total confidentiality
in regard to scores achieved by any individual software product. We
expect manufacturers to maintain the same level of confidentiality with
regard to disclosure of passing scores. Category and overall percentage
scores cannot be disclosed in any media advertising of any CASS or MASS
certified product. Statements like ".... best CASS scores the Postal
Service has ever seen" are also inappropriate. This policy is intended
to level the playing field for all certified products, regardless of
their scores attained. To further reinforce this policy, a statement of
understanding has been added to our application form for all CASS/MASS
applicants to acknowledge. Disclosing or citing scores in any way may be
grounds for revoking CASS/MASS certification status.

The revised policy is as follows for passing tests:

-   CASS: Lowest five scores will be disclosed.

-   MASS: Scores below 98.5% will be provided to both manufacturers and
    end users.

# Status of Progressive Error Inclusion (PEI)

We continue to develop our PEI program. The good news (from the
perspective of the development community) is that we are not yet ready
to deploy it. So PEI will not be incorporated into the CASS grading
process this coming cycle. The bad news is that we expect it to be ready
next cycle. We are hopeful that we will give you feedback regarding PEI
records. We will keep you posted as we move forward.

For those not familiar with PEI, it refers to a new grading approach
that was to be implemented in the 0-01 Cycle. PEI captures all of the
errors in the last passing CASS tests and includes these in your next
CASS Stage 2 File. PEI was only aimed at manufacturers and was to
replace questions rather than add to the 100,000 questions we test for
today, and would continue to be included until the software developer
was able to demonstrate correctly coding these records.

# Revised PS Form 3553

To incorporate the new Delivery Point Validation (DPV) and Early Warning
System (EWS) counts required for next cycle we are slightly modifying
the PS Form 3553. The Quality Statistical Summary (QSS) blocks, which
were introduced last cycle, will now reflect additional blocks to show
the number of records matched to a DPV or EWS record. More detailed
information on EWS is covered later in this document.

# Revised Platform Testing Policy

It appears we are revising all of our policies, but as you may have
already concluded that's the nature of CASS! Nonetheless, we announced
last meeting that we revoked previous policy and require all separate
platforms for a single product to be individually CASS tested and
certified. This policy was not well received by the development
community. However, CASS determined that a baseline was needed to ensure
separate platforms essentially were achieving identical scores.
Unfortunately, the results of separate platform testing were mixed. CASS
does not wish to continue this policy for those developers who
successfully demonstrated their software's ability to achieve consistent
scores. Consequently, the revised policy on separate platform tests
gives developers the opportunity to request an exemption to separate
platform testing based on their past cycle scores. This request should
be submitted to the Certification Department by email, fax, or letter.

# Policy Revision (Multiple Secondary Components)

Last cycle we attempted to address the new Private Mail Box (PMB)
formatting requirements and how CASS software would handle certain
scenarios. With a cycle behind us and with DPV implementation on the
horizon, we believe a change is in order in how software should treat
multiple secondary components.

The primary focus here is when the input address contains multiple
secondary components, which is largely a factor of PMB address formats.
CASS software may now attempt to obtain a higher level of sort by range
checking the separate address components. When one of the secondary
components fall within a valid secondary range and the other component
does not, CASS software must match to the hi-rise exact record. Please
refer to the example below for clarification:

**Input:** 123 Main St #12 #5

**ZIP+4 File Contains:** 123 -- 123 Main St Apt 1 -- 10

**CASS Answer:** 123 MAIN ST APT 5 \# 12

Multiple secondary components logically present several possible
scenarios. For example, cases where the secondary designator is present
on input together with an invalid unit number, and when an additional
secondary component exists (valid within the secondary range), give
preference to the unit designator and default match. CASS is clearly
stating that given an input unit designator, its importance must not be
diminished and software subsequently is not permitted to swap secondary
values to make an exact match even if the other secondary component
falls within the valid secondary range. The following example is
provided for your clarification:

**Input:** 123 Main St *Apt* 12 \# 5

**ZIP+4 File Contains:** 123 --123 Main St Apt 1 - 10

**CASS Answer:** Hi-Rise Default Match

Where the input address contains a secondary unit designator, however
invalid, and a unit number is present and an additional secondary unit
number exists, then giving preference to the unit designator---CASS
software must make an exact match. This increases the potential for
hi-rise coding when these ZIP+4 records are available. These matches
were not previously realized following a more conservative approach to
PMB style addressing. Here's an example:

**Input:** 123 Main St \# 12 Ste 5

**ZIP+4 File Contains:** 123 -- 123 Main St Apt 1 --10

**Output:** #12

123 Main St Apt 5

Nonetheless, we have just one more condition to review. In cases where
multiple secondary components exist and both components fall within a
*valid* secondary range, and no secondary unit designator is
present---CASS software default matches the input to a hi-rise default
record. Here's an example of what we are talking about.

**Input:** 123 Main St \# 12 \# 5

**ZIP+4 File Contains:** 123 -- 123 Main St Apt 1 -- 10

123 -- 123 Main St Apt 11 -- 20

**CASS Answer:** Hi-Rise Default Match

### 

# Ranged Alias Questions

Several developers during this past cycle have raised the issue of near
matches given an input of a ranged Alias record. The ranged Alias
records in subcategory G4 are considered no-match records. Software is
not permitted to make near matches to either the base record or to
another similar sounding ZIP+4 record when the input address makes an
exact match to a ranged Alias record. Here's an example:

### 

Alias File Contains:

+-------------+----------+------------+-------------------+----------+
| #           | Low      | High Range | Street Name       | Post     |
| Record Type | Range    |            |                   | Dir      |
|             |          |            |                   | ectional |
+-------------+----------+------------+-------------------+----------+
| **Alias**   | W10100   | W10199     | HIGHWAY 54        | E        |
+-------------+----------+------------+-------------------+----------+
| **Base**    |          |            | STATE HIGHWAY 54  | E        |
+-------------+----------+------------+-------------------+----------+

Input Stage 1 Record:

5840 HIGHWAY 54 E

BLACK RIVER FALLS WI 54615

Software **Cannot** Match to:

5840 STATE HIGHWAY 54

BLACK RIVER FALLS, WI 54615-5973

### 

# Multiple-Field Addresses with Split Indicia

In the 1999 -- 2000 CASS cycle, we introduced as optional for CASS
certified software, addresses spanning multiple fields or lines.
Although introduced at the time, Stage files have not contained
questions of split indicia, where a multiple component street name is
split between two address lines. Stage files have, for the most part,
limited these addresses to rolling up suffix words and other secondary
information. For the next cycle, however, CASS Stage files and MASS test
decks will contain addresses where one of the address lines may make an
inexact match in the finance number. CASS is stressing that when
software is presented with two address lines, both lines in their
entirety must be considered to arrive at a correct ZIP+4 match. Here is
an example of these address conditions, which CASS has field reports of
miscoding.

Input Stage 1 Record:

1340 SIERRA MADRE

VILLA AVE

PASADENA CA 91107

Software **Cannot** Match to:

1340 SIERRA MADRE BLVD

PASADENA CA 91108-2140

The Correct Match is:

1340 SIERRA MADRE VILLA AVE

PASADENA CA 91107-1531

# Restrictions on Unique Address Matching

The field is reporting cases where software is miscoding addresses which
do not contain unique ZIP Codes on input, but which are matching into
unique ZIP Codes. As you know, the applicable rule here is that software
can only match into a unique ZIP Code when the input address contains a
unique ZIP Code or when a Firm match is available. CASS will place a
greater emphasis in this area. Stage file questions will "tempt"
software to make matches into unique ZIP Codes by either dropping the
unique ZIP Code on an otherwise perfect Hi-rise or street address or by
dropping both the Firm address line and ZIP Code on input.

### Grading Issues

# Delivery Point Validation (DPV)

In support of Address Management's launch of DPV and DSF^2^ licensing,
CASS will offer certification testing. Software attempting DPV
certification must process and successfully achieve a passing score on
either a Merge or a Merge/LOT (or E-LOT) Stage 2 File. CASS will only
evaluate DPV return codes and delivery statistics (for DSF^2^ licensees)
when address-matching software achieves the required accuracy rates for
CASS certification. This applies to all DPV applicants, whether CASS
certification was previously achieved with the same software
configuration or for new software. For DPV basic, DPV certification will
be awarded by individual software configuration. For developers with
multiple configurations, separate applications and processed Stage 2
Files would be necessary. Because the awarding of initial DPV
certification is a function of a licensing process, CASS will not
provide DPV licensees the standard certificates normally associated with
CASS certification.

For cycle 2-03, CASS will not require address matching software
developers to integrate DPV into their address matching software. For
this coming cycle, software developers electing to integrate DPV into
their address matching systems may only employ DPV to delivery point
validate standardized ZIP+4 coded addresses and resolve simple multiple
response conditions.

CASS will modify both Stage 1 and 2 File layouts to incorporate the
various DPV return codes, statistics, counts, and miscellaneous footnote
flags for DSF^2^ licensees. For Stage 2 Files, software attempting
certification will have to correctly produce an output file with the
appropriate DPV confirmation code, and in addition, DSF^2^ applicants
must demonstrate the ability to output the footnote flags as required
under the license agreement.

The following items were presented and discussed during the conference
and help clarify how CASS will evaluate DPV enabled CASS software.

# 

# Multiple Response Handling

Initially, CASS will set some relatively conservative boundaries on the
use of DPV to resolve multiple response conditions. Rather than undo
past CASS rules regarding multiple response conditions and to promote
coding consistency across software products, CASS will limit where DPV
may select records among candidate records in a stack. DPV enabled
software may elect to code where input address ambiguities

(i.e., missing suffixes, misspelled street names, etc.) and data
anomalies exist within the ZIP+4 File. In addition, if no previous CASS
rule directs a match, DPV enabled software may elect to code when a
single DPV candidate is available and all records on the stack have been
passed through DPV. If CASS has already issued a ruling on a multiple
response condition permitting a match, then DPV cannot attempt to
resolve it.

Input address ambiguities or multiple response conditions may be
resolved through DPV. For example, CASS does not allow software to
resolve multiple responses in cases where two records are equal if the
carrier routes are different. However, DPV enabled software may elect to
resolve these questions.

######## 

######## DPV May Match when All Address Elements Equal Other Than the Carrier Route 

**Input:** 6 Station St

Carnegie PA 15106

**ZIP+4 File Contains:**

  ----------- ----------- ----------- ------------ ----------- -----------
  **Primary               **Street    **Suffix**   **ZIP       **CRID**
  Range**                 Name**                   Code**      

  6           6           STATION     ST           15106       C008

  6           6           STATION     ST           15106       C020
  ----------- ----------- ----------- ------------ ----------- -----------

**Output**: Match to the Record that DPV confirms.

Multiple response questions typically found in Stage 2 Files are
composed from two ZIP+4 records that are equal, but contain different
ZIP Codes. CASS drops both input records' ZIP codes to generate multiple
response conditions. The example below illustrates this condition where
DPV enabled software *could* elect to code, given only one record
confirms through DPV.

######## DPV May Match When Multiple Response Conditions Exist Due to No Input ZIP Code

**Input:** 2 Knowltan Ave

Buffalo NY

**ZIP+4 File Contains:**

  ----------- ----- -------------- ------------ --------- ------------- ---------- --------
  **Primary         **Street       **Suffix**   **ZIP     **City**      **CRID**   **Plus
  Range**           Name**                      Code**                             4**

  2           98    KNOWLTAN       AVE          14218     BUFFALO       C010       3106

  2           98    KNOWLTAN       AVE          14217     BUFFALO       C027       2723
  ----------- ----- -------------- ------------ --------- ------------- ---------- --------

**Output:** ZIP+4 Code to the DPV confirmed record.

Over past cycles, CASS has developed discretionary rules regarding the
ZIP+4 coding when certain multiple response conditions occur. These
rules will remain in effect for the foreseeable future for DPV enabled
engines. Again, consistency in coding among all products and a "going
slow" approach to DPV coding are overriding guidelines here.

DPV Must Not Make a Match When CASS Has Already Provided Matching Rules

**Input:** 306 S Monroe St

Versailles MO 65084

**ZIP+4 File Contains and DPV Flags Show:**

  ----------- ------ --------------------- ---------- ------------ --------- --------- ---------
  **Primary          **Pre-Directional**   **Street   **Suffix**   **ZIP     **Plus    **DPV**
  Range**                                  Name**                  Code**    4**       

  300         306    S                     MONROE     ST           65084     1386      Y

  300         398    S                     MONROE     ST           65084     1300      N
  ----------- ------ --------------------- ---------- ------------ --------- --------- ---------

**Output:** 306 S MONROE ST (Code to the Lowest ZIP+4)

VERSAILLES MO 65084-1300

######## DPV Must Not Violate the Cardinal Rule

**Input:** 6 NE Johnny Lytle Ave

Springfield OH 45506

**ZIP+4 File Contains and DPV Shows:**

  ----------- ------ --------------------- ---------------- ------------ ---------- -------- ---------
  **Primary          **Pre-Directional**   **Street Name**  **Suffix**   **ZIP      **Plus   **DPV**
  Range**                                                                Code**     4**      

  2           98     E                     JOHNNY LYTLE     AVE          45506      2649     N

  2           98     W                     JOHNNY LYTLE     AVE          45506      2651     Y
  ----------- ------ --------------------- ---------------- ------------ ---------- -------- ---------

**Output:** No Match/Return Input

######## DPV May Elect to Resolve Multiple Responses When the Input Address is Missing or Contains Invalid Suffix Words

**Input:** 1108 11^th^ SE

Jamestown ND 58401

**ZIP+4 File Contains:**

  ----------- -------- ------------- ------------ ---------------------- -------- -------- ---------
  **Primary            **Street      **Suffix**   **Post-Directional**   **ZIP    **Plus   **DPV**
  Range**              Name**                                            Code**   4**      

  1100        1198     11^TH^        ST           SE                     58401    5835     Y

  1100        1198     11^TH^        AVE          SE                     58401    5829     N
  ----------- -------- ------------- ------------ ---------------------- -------- -------- ---------

**Output:** 1108 11^th^ ST SE

Jamestown ND 58401-5835

DPV May Attempt to Select a Record from Multiple Candidates When Only a
Change of a Suffix or Directional Component is Affected

CASS is purposely making this distinction for software developers to
limit matches when only a change of a suffix or directional component is
affected. Street name variations are too variable at this juncture and
CASS would like to proceed with caution as CASS enters the realm of DPV
coding.

**Input:** 123 Main St

**ZIP+4 File Contains:**

+------+-------+----------------+---------+----------------+----------+
| *    |       | **Street       | **S     | **Post         | **DPV**  |
| *Pri |       | Name**         | uffix** | -Directional** |          |
| mary |       |                |         |                |          |
| Ran  |       |                |         |                |          |
| ge** |       |                |         |                |          |
+------+-------+----------------+---------+----------------+----------+
| 101  | 199   | MAIN           | ST      | N              | N        |
+------+-------+----------------+---------+----------------+----------+
| 101  | 199   | MAIN           | ST      | S              | N        |
+------+-------+----------------+---------+----------------+----------+
| 101  | 199   | ######### MANE | AVE     |                | Y        |
+------+-------+----------------+---------+----------------+----------+

**Output:** No Match/Return Input

**Input:** 123 Main St

**ZIP+4 File Contains:**

+------+-------+----------------+---------+----------------+----------+
| *    |       | **Street       | **S     | **Post         | **DPV**  |
| *Pri |       | Name**         | uffix** | -Directional** |          |
| mary |       |                |         |                |          |
| Ran  |       |                |         |                |          |
| ge** |       |                |         |                |          |
+------+-------+----------------+---------+----------------+----------+
| 101  | 199   | MAIN           | ST      | N              | N        |
+------+-------+----------------+---------+----------------+----------+
| 101  | 199   | MAIN           | ST      | S              | N        |
+------+-------+----------------+---------+----------------+----------+
| 101  | 199   | ######### MAIN | AVE     |                | Y        |
+------+-------+----------------+---------+----------------+----------+

**Output:** DPV May Resolve

DPV May Elect to Confirm a Secondary Component When the Input Address
Contains Multiple "#" Signs but Only One Confirms

**Input:** 2095 Exeter Rd #128 #80

Germantown TN 38138

**ZIP+4 File Contains:**

  -------- ----------- ------- -------------- ------------ ------------- ------ -------- --------
  **Rec    **Primary           **Street       **Suffix**   **Secondary          **ZIP    **Plus
  Type**   Range**             Name**                      Range**              Code**   4**

  H        2095        2095    EXETER         RD           2             98     38138    1234

  H        2095        2095    EXETER         RD                                38138    1235
  -------- ----------- ------- -------------- ------------ ------------- ------ -------- --------

# 

# DPV Confirms Secondary Suite Number 80

**Output:** #128

2095 Exeter Rd Ste 80

Germantown TN 38138-1234

**DPV Confirms Secondary Suite Number 80 and CMRA Indicator is
Returned**

**Output:** PMB 128

2095 Exeter Rd Ste 80 (or PMB 128 on address line 1)

Germantown TN 38138-1234

Note: For street level matches where the input contains a "#" sign and
the CMRA indicator is returned from DPV, software must not change "#"
sign to "PMB". This policy is grounded on the rationale that the "#" may
or may not indicate a PMB box number.

DPV Must Not Confirm a Secondary Component When the Input Address
Contains a Secondary Unit Designator and a "#" Sign

**Input:** 2095 Exeter Rd Ste 128 #80

Germantown TN 38138

**ZIP+4 File Contains:**

  ----------- -------- ----------- ------------ ------------- ------ ---------- -----------
  **Primary            **Street    **Suffix**   **Secondary          **ZIP**    **Plus 4**
  Range**              Name**                   Range**                         

  2095        2095     EXETER      RD           2             98     38138      1234

  2095        2095     EXETER      RD                                38138      1235
  ----------- -------- ----------- ------------ ------------- ------ ---------- -----------

DPV Cannot Swap Secondary Values When Secondary Unit Designators are
Present (Software Submits 2095 and 128 to DPV)

**Output:** 2095 Exeter Rd Ste 128 #80 (Default Match)

Germantown TN 38138-1235

# 

# DPV Return Codes

DPV enabled software must display certain return codes for CASS
evaluation. The following four return codes are considered required when
performing DPV:

+------------+------------------------------------------+-------------+
| **Return   | ######### Definition                     | ######### A |
| Code**     |                                          | pplicable R |
|            |                                          | ecord Types |
+------------+------------------------------------------+-------------+
| #          | No Delivery Point Validated              | All         |
| ######## N |                                          |             |
+------------+------------------------------------------+-------------+
| **Y**      | Delivery Point Validated /Primary Valid  | All         |
|            | and Secondary Number (When Present)      |             |
|            | Valid                                    |             |
+------------+------------------------------------------+-------------+
| **S**      | Valid Primary Number; But Secondary      | All         |
|            | (Primary for Rural Route) Present and is |             |
|            | Not Confirmed                            |             |
+------------+------------------------------------------+-------------+
| **D**      | Valid Primary; Input Missing Secondary   | All, but    |
|            | (Primary for Rural Route)                | Street      |
+------------+------------------------------------------+-------------+

# DPV Secondary Information 

DPV enabled software must attempt to confirm both the primary and
secondary number when present. When the DPV return code equals "N",
software must attempt to confirm the primary number without the parsed
secondary. If the primary number confirms, software returns the
standardized output and sets the DPV code to "S". If the primary number
does not confirm, software must return the output address, as usual,
adhering to CASS requirements.

When the input address has no parsed secondary number and the ZIP+4
record is a default match, and the DPV return code initially equals "Y",
software then is required to set the DPV value to "D"--- or default to
indicate that the secondary was missing. For rural route type records,
if the input address is missing the box number, set the return code to
"D"; if the box number is present, but unconfirmed, set the return code
to "S". When the final DPV code is obtained, software must query the DPV
Commercial Mail Receiving Agency (CMRA) table.

As a final note, secondary information must always be submitted for DPV
confirmation when present in the input address regardless of the level
of match obtained. This is important, because some street records
contain secondary information and this bit of information may be
critical to delivery. CASS has always taken the position that software
should not drop secondary information even when the DPV return code is
"N".

# 

# 

# 

# 

# Early Warning System (EWS)

Software must demonstrate the ability to *not ZIP+4* code when making an
exact match to an EWS record. This functionality will be tested in
questions presented in Stage files in cycle 2-03. Because timing is key
to identifying valid EWS records*, CASS will require software developers
to use the same product month from which the Stage 2 File was built*.
Developers must key off of the monthly Stage 1 File release to know when
to update to the next product month for CASS certification testing
purposes only. The objective here is to reduce the occurrences of no
matching into EWS records due to a developer's load of a subsequent
product month. In addition, CASS has always taken the position that for
optimum results in matching accuracy, developers should process stage
files using the same product month. Now CASS is just taking the next
logical step and requiring this "syncing up product months" with the
introduction of EWS. Weekly EWS files will be posted to the RIBBS server
and CASS will extract candidate questions from the most recent EWS
posting prior to stage build.

CASS is not requiring end-users to use EWS. However, we are requiring
CASS manufacturers to employ EWS for both CASS and MASS certification
and to offer it as an option for their end users. The mechanics of how
developers implement EWS in their application is solely left to the
discretion of software developers. The Postal Service will at every
opportunity, highlight the benefits of integrating EWS into their normal
mail processing activities. CASS will also not prescribe an update
frequency for the manufacturers to distribute EWS to end-users or how
this file is made available or distributed to end-users. These issues
are not certification related, but more related to a product's offering,
its packaging and deployment application that is product specific.

The potential for miscoding of valid new addresses increases with the
age of the ZIP+4 File in use by the mailer. Valid addresses miscoded due
to inexact address matches (where some address line component is either
added or changed) available in the current ZIP+4 File is the root cause
of what is termed "Broken Address Syndrome". Once an address is
broken---coded to another valid address---the effect is permanent
without manual intervention.

EWS consists of a table of records containing partial address
information limited to the street name, pre- and post-directionals, and
a ZIP Code. EWS records are culled from a weekly-generated ZIP+4 File.
For an address record to be EWS eligible, it must be an address *not*
present on the most recent monthly production ZIP+4 File and, as an
input address and processed through address matching software,
potentially could incorrectly obtain a ZIP+4 code to another address
record. For example, given the following address.

**Input:** 100 S Bonnie Ct

> Chauvin LA 70344

ZIP+4 File Contains:

  -------------- ------------ ----------- ------- --- ------- -------- ----------------- ----- ------------ ------------ -------------
  **Database**                **Primary               **Pre            **Primary Name**        **Suffix**                **ZIP/ZIP+4
                              Range**                 Dir**                                                              Code**

  **EWS**        Not                              S           BONNIE                     CT                 70344        
                 Applicable                                                                                              

  **ZIP+4**      100                      198                 BONNIE                     AVE                70344-3940   
  -------------- ------------ ----------- ------- --- ------- -------- ----------------- ----- ------------ ------------ -------------

**Output** (Incorrect)**:** 100 Bonnie Ave

Chauvin LA 70344-3930

In the above scenario, S Bonnie Ct is a record extracted from the weekly
ZIP+4 File and as an input address could have potentially coded to an
inexact match of 70344-3940. CASS will expect software to no-match EWS
records and set a flag in the Stage 2 test address record. For CASS
testing purposes, an exact match is defined as a match to all components
of the EWS record to include the ZIP Code.

# Chasing the Base (or Hi-Rise Alternate Coding Rules)

CASS has determined that matches made to hi-rise delivery point
alternate records, when the input address contains valid secondary
address unit numbers, can not obtain optimum sequencing via automation
since '99' is assigned as the delivery point. To improve the sequencing
of this mail, CASS will require address-matching software to "chase the
base" or to find the hi-rise base record associated with the alternate
record when presented with this condition.

Software, when presented with an input address matching to a hi-rise
delivery point alternate record will determine the base associated with
the alternate record. Every alternate hi-rise record is associated with
a base record in the ZIP+4 File. Using ZIP+4, software locates the
hi-rise base default record for any given alternate record. Once
obtained, the hi-rise default base record is appended with secondary
address information and is resubmitted. If the secondary unit number is
valid within a secondary range, then software must make the ZIP+4 exact
match. If no secondary range is valid for the input, then software
*reverts back* to the originally matched hi-rise alternate record. An
example is supplied for clarifying "chasing the base" process:

Input: 155 BANK ST #C913

> NEW YORK NY 10014

**ZIP+4 File Contains:**

  ---------- ----------- ------ ---------- ------------ ------------- ------- ------------ -------- --------
  **Record   **Primary          **Street   **Suffix**   **Secondary           **Base/Alt   **ZIP    **Plus
  Type**     Range**            Name**                  Range**               Code**       Code**   4**

  H          155         155    BANK       ST                                 A            10014    2010

  H          463         463    WEST       ST                                 B            10014    2010

  H          463         463    WEST       ST           C907          C922                 10014    2038
  ---------- ----------- ------ ---------- ------------ ------------- ------- ------------ -------- --------

**Output:** 463 WEST ST APT C913

> NEW YORK, NY 10014-2038 (33)

# 

# Recombination

For various reasons, customers do not always represent their addresses
in the standardized format as reflected in the ZIP+4 File. CASS has
determined that a greater number of hi-rise exact assignments are
possible when software recombines specific primary address values with
secondary address values under defined conditions. Through this
recombination activity, CASS certified software might increase hi-rise
depth-of-code matches.

Recognizing this reality of poor address hygiene, CASS will require
software to transpose primary address number values that, when combined
with secondary address information, obtains a hi-rise exact match by
matching to a valid secondary address range in the ZIP+4 File. CASS will
also test for secondary address values transposed with other secondary
address values that through recombination a hi-rise exact match is
achieved.

In response to the industry's concerns, CASS is declaring this matching
rule *optional* for this cycle. In addition, for the first time in known
history, CASS will assess bonus percentage points within the category
recombination assigned and where software has demonstrated recombination
successfully.

Software may recombine the input address that contains a secondary
value, matches to a street record, and an element of the primary number
was not used in determining the match. The following table is guidance
regarding recombination.

  ----------------------------- -----------------------------------------
  Through recombining the       
  primary....                   

                                Trailing Alpha

                                Alphanumeric (hyphenated or not
                                hyphenated)

                                Hyphenated Numeric

                                Or hyphenated numeric-alpha

  .... with the input hi-rise   
  secondary a match to an exact 
  hi-rise record is achieved    
  (using current transposition  
  rules).                       

  Or by recombining separate    
  secondary components into a   
  single value result in an     
  exact match to a hi-rise      
  exact record is achieved.     
  ----------------------------- -----------------------------------------

Here are more examples of where recombination would be appropriate.

ZIP+4 File Contains:

+-------------+------+------+--------------+-----+------+-------------+
| #########   | *    |      | **Street     | **  |      | **ZIP+4     |
| Record Type | *Pri |      | Name**       | Sec |      | Code**      |
|             | mary |      |              | ond |      |             |
|             | Ran  |      |              | ary |      |             |
|             | ge** |      |              | R   |      |             |
|             |      |      |              | ang |      |             |
|             |      |      |              | e** |      |             |
+-------------+------+------+--------------+-----+------+-------------+
| S           | 1    | 85   | Wiley Parker |     |      | 4017        |
|             |      |      | Rd           |     |      |             |
+-------------+------+------+--------------+-----+------+-------------+
| H           | 31   | 31   | Wiley Parker |     |      | 4076        |
|             |      |      | Rd           |     |      |             |
+-------------+------+------+--------------+-----+------+-------------+
| H           | 31   | 31   | Wiley Parker | J2  | J2   | 5803        |
|             |      |      | Rd           |     |      |             |
+-------------+------+------+--------------+-----+------+-------------+
| S           | 250  | 398  | Wiley Parker |     |      | 4028        |
|             |      |      | Rd           |     |      |             |
+-------------+------+------+--------------+-----+------+-------------+

  ------------------------ ------------------------ ----------------------
  **Input Address**        **Applicable Condition** **Output Address**

  31J Wiley Parker Rd #2   Trailing Alpha           31 Wiley Parker Rd Ste
                                                    J2

  31-2 Wiley Parker Rd #J  Hyphenated Numeric       31 Wiley Parker Rd Ste
                                                    J2

  31-J2 Wiley Parker Rd    Hyphenated Alphanumeric  31 Wiley Parker Rd Ste
                                                    J2

  31-J Wiley Parker Rd #2  Trailing Alpha           31 Wiley Parker Rd Ste
                                                    J2

  31 Wiley Parker Rd #2 #J Secondary Transposition  31 Wiley Parker Rd Ste
                                                    J2
  ------------------------ ------------------------ ----------------------

# 

# Preferred Last Line City State Key

Use of the ZIP+4 Preferred Last Line (PLL) City-State Key by CASS
software has been narrowly defined, and until now has had little value
or importance in address matching. Output of the ZIP+4 PLL was limited
to cases where the input address is submitted with a ZIP Code only, or
when the input city name is not in the City-State File or, is altogether
unrecognizable. CASS is not changing these existing rules, nor is CASS
changing the rules established two cycles ago for arriving at a match
and how Last Line Logic supported software selecting the correct address
records. This new policy only affects output; it has no bearing on the
selection of candidate records in the matching process. The purpose of
this discussion affects only the output city name and how it is only
determined after the ZIP+4 record is selected.

CASS is introducing the idea of the *Default City Name* at the 5-Digit
level and the *Override City Name* (ZIP+4 PLL) at the ZIP+4 level. As
you may know, and likely utilize in your current address-matching
product, each city name and any possible representation of that city
name in the City-State File is assigned a unique key. These keys assist
software in properly identifying the input city name, the default city
name (PLL), and the city name for a particular block face (ZIP+4 PLL).

The 5-Digit PLL can also be considered to be the default city name for a
ZIP Code. In fact, for most ZIP+4 records, the ZIP+4 PLL City-State Key
and the default City-State key are the same. However, in cases where the
ZIP+4 PLL key is different from the default city name, CASS is declaring
this the *Override* city name. Generally the rule is when an override
condition is present and an acceptable city name is on the input address
record, the override takes precedence over the input city name.

When an override city name is present, it takes precedence over a
thirteen-character city name abbreviation. This new policy modifies an
existing CASS rule. If the input city name is a valid abbreviation---on
the City-State File---then CASS certified software was expected to
return it in abbreviated fashion on the output. Software must now
determine whether an override situation exists. If so, software may
return either the override city name spelled-out version, or the
abbreviated city name, if applicable.

Also recall, a non-mailing name is equivalent to the default city name.
So again, software must determine whether an override condition is
present when the input city name is a non-mailing name.

Given various scenarios, the table below is designed to assist software
developers in selecting the correct city name for output purposes. These
scenarios all assume the input city name is an acceptable mailing name
and not a non-mailing name.

  -------------- ------------------- ---------------------- ----------------
  **Acceptable   **5-Digit Preferred **ZIP+4 Preferred Last **CASS
  City Name On   Last Line City      Line City State Key**  Standardized
  Input**        State Key                                  City Name On
                 (Default)**                                Output**

  Germantown     Germantown          Germantown             Germantown

  Memphis        Germantown          Germantown             Memphis

  Germantown     Memphis             Germantown             Germantown
                                     **(Override)**         

  Cordova        Memphis             Germantown             Germantown
                                     **(Override)**         
  -------------- ------------------- ---------------------- ----------------

# Record Type Code

CASS will require certified software to return the Record Type Code in
all ZIP+4 matches. The level match code facilitates identifying or
confirming certain software matches when delivery point assignments are
erroneous. CASS will provide a revised answer file layout

### MASS Issues

# Machine Identifier Proposal

Multiline manufacturers should have, by this time, downloaded their
machine IDs from the RIBBS web site and be well into completing the
process of getting the IDs sprayed onto mail pieces. The Postal Service
delayed implementation of the machine identifier program until January
1, 2002. This date may be considered a not earlier than date, unless
otherwise approved. The mandatory compliance date is now February 23,
2002. No other changes were recommended. The delay allows headquarters
Postal Service sufficient time to coordinate with various offices
affected by this change. We continue to reconcile missing and
conflicting serial numbers between MASS and *FASTforward*®.
Manufacturers should contact the Certification Department should they
find discrepancies in any of the identification data provided. The
importance of this matter will obviously grow as we move closer to the
end of the calendar year. Again, contact the Certification Department
with any concerns regarding compliance with this vital program.

# Grading Issues

As previously mentioned, MASS will introduce no significant changes over
last cycle's requirements due to development efforts which software and
hardware manufacturers are anticipated to devote to DPV integration.
MASS scores will remain at 98% with no increase in the number of fonts
or in the percentage of pieces containing the variable fonts introduced
the cycle before last. No new fonts will be introduced this cycle, but
the existing optional fonts will now be required.

# Misread/Miscodes

The penalty for Misread/Miscodes, introduced last cycle, will remain
fixed at a factor of 1.5 per assessed error, however, we are expanding
our definition of this error type to include any change in primary
number. The impact of this error type on overall scores this past cycle
were negligible, largely due to a very narrow definition of a primary
number change from, for example, four digits to three. Again,
manufacturers should expect a degradation in test scores for customers
when their miscoded questions also affect primary number values.

# Reject Allowance

The *reject allowance* will also continue to remain at 7.5%. Again, the
rate was increased to allow MLOCRs to opt out---not spray a barcode when
a level of confidence is not achieved. This level of confidence is
solely at the discretion of each manufacturer. Although manufacturers
have stated that the reject rate increase has not really helped them in
reducing their true error rate, MASS will continue to offer this as an
incentive for commercial MLOCRs to not spray when confidence levels are
low.

# Trailing Alpha File

MASS will also continue to make available the trailing alpha file each
month. Again, this file contains all of the hi-rise secondary ranges
which have trailing alphas assigned. The file is made available to
enhance the ability of MLOCRs to accurately code when alpha and numeric
character collisions occur. Although the utility of this file has been
mixed, at best, MASS will continue to provide this file with the
anticipation that coding accuracy levels in this area will improve.

# Pound Signs and New Test/Audit Envelopes

MASS has taken a couple of positive steps to improve the readability of
test pieces for optical readers. The first pertains to the notorious "#"
sign in secondary addresses. Most manufacturers' systems have difficulty
in coding addresses where a "#" sign is used to denote a secondary unit
number. They also have expressed concern about consistently obtaining
poor read rates because of this character's lack of white space. MASS
will continue to include questions containing the "#" sign, however, in
response to these concerns, the "#" sign font has been successfully
edited to *increase* the white space in the middle of the character.
This should effectively neutralize this issue.

Secondly, MASS is transitioning to a new, improved test envelope. This
envelope will contain a reduced-glare glassine cover aimed at enhancing
readability. MASS is sending samples of this new envelope over the next
few days to all MASS manufacturers.

# Handwriting Technologies 

Over this past year many manufacturers have been exploring the
possibility of incorporating handwriting technologies into their present
inventory of automated systems. Similarly, hardware developers have
sought MASS' position regarding integration of handwriting technologies
from a certification perspective. Manufacturers who are integrating this
technology in order to increase existing machine print read rates will
require additional testing for manufacturer certification. MASS will
provide a test deck to be processed with only this technology enabled.
Manufacturers will have to obtain 98% accuracy on both test decks. End
users who wish to use this technology would simply take a standard MASS
test.

However, MASS is concerned with off-line systems designed to replace
remote and local video encoding operations where hand print or any
combination of hand writing is eligible to receive a POSTNET® barcode.
MASS has not developed a test deck to test the accuracy of non-machine
hand printing or handwriting. The ability to encode handwritten
addresses places the scope of this technology in another arena from a
MASS perspective.

Nonetheless, MASS has determined that developing a handwritten test deck
would be ineffectual and problematic, at best, in establishing some
level of barcoding accuracy rate. Therefore, MASS will not offer such
testing pending any other facts or opinions that may take this issue in
another direction altogether. Should MASS begin receiving field reports
that MLOCR applied barcode mail with handwritten addresses is being
miscoded in significant numbers, manufacturers should be prepared to
immediately terminate the use of this technology until the miscoding
problems are resolved.

# Recombination for MASS

MASS test decks will contain pieces with addresses where recombination,
as discussed above, is required to achieve the correct barcode. These
pieces will be regarded optional and if successfully coded, an
additional bonus percentage will be assessed (exact amount to be
determined). However, if coded in error, an incorrect answer would
likewise be assessed. Manufacturers will have every opportunity to
evaluate their system's ability to accurately exercise recombination
through Stage 1 test decks. These test decks are available at no cost to
manufacturers only and will consist of our standard 3500 piece test deck
with answers in the upper left window---identical to the decks made
available in the previous cycle. Since the barcode is the answer
evaluated, manufacturers would demonstrate this capability by coding to
the highest depth of sort given a certain input address requiring
recombination. A lesser level of sort would be considered an error.

# 

# Concatenated Last Lines

MASS test addresses will now offer questions where components of the
Last Line are strung together or concatenated. For example, questions
may appear where the city and ZIP Code or city and state, is
concatenated. Address lines will be comprised of records where they do
not necessarily influence the match. These address conditions have been
reported to cause miscodes. The example below is an actual address
miscoded and reported by Postal field representatives.

PO BOX 1319

PORT WASHINGTON NY11050

This address was being coded to:

PO BOX 1319

WEST PORT WA 98595-1319