# Reviewing a document-access evaluation

Authored evaluation sample · not client work or a model benchmark

This is a self-contained reasoning sample, not a production authorization library.

## Task contract

Return unique document IDs from the actor’s tenant, excluding archived documents. Within that tenant, include public documents and documents owned by the actor. Do not mutate the input. Output order is not specified. Inputs follow the schema shown below; authentication and database authorization are outside this function’s scope.

## Fixture

```javascript
const actor = { id: 'u1', tenantId: 't1' };
const documents = [
  { id: 'b', tenantId: 't1', ownerId: 'u2', visibility: 'public', archived: false },
  { id: 'a', tenantId: 't1', ownerId: 'u1', visibility: 'private', archived: false },
  { id: 'x', tenantId: 't2', ownerId: 'u1', visibility: 'private', archived: false },
  { id: 'c', tenantId: 't1', ownerId: 'u1', visibility: 'private', archived: true },
  { id: 'd', tenantId: 't1', ownerId: 'u2', visibility: 'private', archived: false },
];
```

Expected IDs: a and b, once each, in either order. The empty input returns []. Repeating a visible document must not repeat its ID. The input must remain unchanged.

## Valid reference implementation

```javascript
function visibleDocumentIds(documents, actor) {
  return [...new Set(documents
    .filter(doc => doc.tenantId === actor.tenantId
      && !doc.archived
      && (doc.visibility === 'public' || doc.ownerId === actor.id))
    .map(doc => doc.id))].sort();
}
```

## Defective candidate

```javascript
function visibleDocumentIds(documents, actor) {
  return [...new Set(documents
    .filter(doc => !doc.archived
      && ((doc.tenantId === actor.tenantId && doc.visibility === 'public')
        || doc.ownerId === actor.id))
    .map(doc => doc.id))].sort();
}
```

## Review record

### Solution defect

An ownership check bypasses the tenant boundary.

Evidence: The defective candidate includes document x: it belongs to the actor, but to a different tenant.

Disposition: Reject this candidate. Tenant isolation must apply to both public and owner-visible documents.

### Grader defect

A correct result fails an unstated ordering rule.

Evidence: The reference returns [a, b]. A grader expecting [b, a] rejects it even though the task does not require an order.

Disposition: Correct the grader. Compare the expected IDs without imposing order, and separately check uniqueness and input preservation.

### Specification gap

“Documents the user can access” is not a complete task.

Evidence: That shorter draft leaves tenant boundaries, archived records, ownership and duplicates undefined.

Disposition: Clarify these rules before collecting judgments. Do not classify a solution as wrong based on requirements absent from its task.

## Reproduce the decisive checks

Run each implementation with the fixture above using Node.js. The reference returns ['a', 'b']; the defective candidate returns ['a', 'b', 'x']. Strict equality with ['b', 'a'] wrongly rejects the reference. An order-independent membership check accepts it, but must be combined with uniqueness and non-mutation checks.

## Limits and review resolution

This sample has no measured model score, client data, independent reviewer count or certification. Reviewers should separate implementation defects from task or grader defects. If a criterion is disputed, record the evidence and unresolved question, then clarify the contract with the task owner before finalizing the label. A valid alternative implementation should not be rejected merely because it differs from the reference.