diff --git a/Frameworks/Account/CloudKit/CloudKitArticlesZone.swift b/Frameworks/Account/CloudKit/CloudKitArticlesZone.swift
index 080799ed8..8a11fd951 100644
--- a/Frameworks/Account/CloudKit/CloudKitArticlesZone.swift
+++ b/Frameworks/Account/CloudKit/CloudKitArticlesZone.swift
@@ -147,7 +147,6 @@ private extension CloudKitArticlesZone {
 
 	func makeArticleRecordsIfNecessary(_ articles: Set<Article>, completion: @escaping ((Result<[CKRecord], Error>) -> Void)) {
 		let group = DispatchGroup()
-		var errorOccurred = false
 		var records = [CKRecord]()
 
 		for article in articles {
@@ -164,9 +163,8 @@ private extension CloudKitArticlesZone {
 					if !recordFound {
 						records.append(contentsOf:  self.makeArticleRecords(article))
 					}
-				case .failure(let error):
-					errorOccurred = true
-					os_log(.error, log: self.log, "Error occurred while checking for existing articles: %@", error.localizedDescription)
+				case .failure:
+					records.append(contentsOf:  self.makeArticleRecords(article))
 				}
 				group.leave()
 			}
@@ -174,11 +172,7 @@ private extension CloudKitArticlesZone {
 		}
 		
 		group.notify(queue: DispatchQueue.main) {
-			if errorOccurred {
-				completion(.failure(CloudKitZoneError.unknown))
-			} else {
-				completion(.success(records))
-			}
+			completion(.success(records))
 		}
 	}
 	
diff --git a/Mac/Preferences/Accounts/AccountsDetailViewController.swift b/Mac/Preferences/Accounts/AccountsDetailViewController.swift
index a33d7bc66..5ca513c02 100644
--- a/Mac/Preferences/Accounts/AccountsDetailViewController.swift
+++ b/Mac/Preferences/Accounts/AccountsDetailViewController.swift
@@ -33,8 +33,7 @@ final class AccountsDetailViewController: NSViewController, NSTextFieldDelegate
 			return true
 		}
 		switch account.type {
-		case .onMyMac,
-			 .feedly:
+		case .onMyMac, .cloudKit, .feedly:
 			return true
 		default:
 			return false
diff --git a/Technotes/RetentionPolicy.markdown b/Technotes/RetentionPolicy.markdown
new file mode 100644
index 000000000..c86799409
--- /dev/null
+++ b/Technotes/RetentionPolicy.markdown
@@ -0,0 +1,72 @@
+# Retention Policy
+
+This is a user interface issue, primarily — what articles should be displayed to the user?
+
+This article answers that question, and it describes how the decisions are implemented.
+
+And, at the end, there’s a special note about why we have limits at all.
+
+## Web-Based Sync Systems
+
+When used with Feedbin, Feedly, and other syncing systems, NetNewsWire should show the same unread articles that the user would see in the browser-based version. (The unread counts would necessarily be the same in NetNewsWire and on the web.)
+
+It should also show the exact same starred items.
+
+It does *not* have to show the exact same read items. Instead, it will show read items that arrived locally in the last 90 days.
+
+### Database Queries
+
+Most queries for articles should include this logic:
+
+* If an article is userDeleted, don’t show it
+* If an article is starred or unread, show it no matter what
+* If an article is read, and status.dateArrived < 90 days ago, then show it
+
+### Database Cleanup
+
+Database cleanups to do at startup:
+
+* Delete articles from feeds no-longer-subscribed-to, unless starred
+* Delete read/not-starred articles where status.dateArrived > 90 days go (because these wouldn’t be shown in the UI)
+* Delete statuses where status is read, not starred, and not userDeleted, and dateArrived > 180 days ago, and the associated article no longer exists in the articles table.
+
+We keep statuses a bit longer than articles, in case an article comes back. But we don’t keep most statuses forever.
+
+## Local and iCloud Accounts
+
+NetNewsWire should show articles that are currently in the feed. When an article drops off the feed, it no longer displays in the UI.
+
+The one exception is starred articles: as with sync systems, starred articles are kept forever.
+
+### Database Queries
+
+Most queries for articles should include this logic:
+
+* If an article is userDeleted, don’t show it
+* If an article is starred, show it no matter what
+
+### Database Cleanup
+
+Database cleanups to do while running:
+
+* When processing a feed, delete articles that no longer appear in the feed — unless a feed comes back empty (with zero articles); do nothing in that case
+
+Database cleanups to do at startup:
+
+* Delete articles from feeds no-longer-subscribed-to, unless starred
+* Delete statuses where not starred, not userDeleted, and dateArrived > 30 days ago, and the associated article no longer exists in the articles table.
+
+We keep statuses a bit longer than articles, in case an article comes back. (An article could come back when, for example, a publisher reconfigures their feed so that it includes more items. This could bring back articles that had previously fallen off the feed.)
+
+## Why Do We Have Limits At All?
+
+Most people don’t want NetNewsWire to just keep holding on to everything forever, but a few people do.
+
+And that’s understandable. It’s pretty cool to have a personal backup of your favorite parts of the web. It’s great for researchers, journalists, and bloggers.
+
+But the more articles we keep, the larger the database gets. It’s already not unusual for a database to become 1GB in size — but we can’t let it grow to many times that, because it will:
+
+* Make NetNewsWire unacceptably slow
+* Take up an inordinate amount of disk space
+
+So we need to have limits. The point of NetNewsWire is to keep up with what’s new: it’s *not* an archiving system. So we’ve defined “what’s new” expansively, but not so expansively that we don’t have a definition for “what’s old.”