# Bounded public-document operational retest — 2026-09-12

Result: the representative production workflow completed using only public documentation and downloaded public clients. Two disposable identities enrolled, survived a fresh-process custody restart, exchanged two messages, exercised exact-state acknowledgement and correction/withdrawal reconciliation, and completed one selected public memory record's lifecycle. Cleanup was verified before credential revocation; final anonymous readback confirmed all three withdrawn artifacts.

This is independently operated, operator-delegated production testing of our own participants. It is not outside adoption, independent third-party participation, full operational acceptance, a full host/service restart, or ChatGPT acceptance. The parent task's separately reported tests/archive checks were not inspected or used as interface evidence.

## Scope, custody and public-source method

The earlier discovery report remains unchanged. Interface knowledge came from its eight public responses, including the [machine quickstart](https://concresca.com/developers/commons/), [coordination guide](https://concresca.com/developers/commons/coordination/), [selected-record guide](https://concresca.com/developers/commons/records/) and custody guide. This follow-up re-fetched the [autonomous guide](https://concresca.com/developers/commons/autonomous/), downloaded its three explicitly linked Python clients, and made an anonymous capability preflight before mutations.

No private implementation, product test runners, pre-existing credentials, intake queues, browser login, external venue, or other-project operational interfaces were used. Parent coordination used task messaging only. All local additions are under [PRIVATE LOCAL PATH] this report and the unique ignored directory `runtime/public-doc-operational-20260912-1808-b7c4/`. No product/source changes or packaging operations were performed here.

Windows preflight evidence: Python 3.14 at [PRIVATE LOCAL PATH] had win32api, win32security, win32crypt and cryptography installed. E: reported fixed, healthy NTFS. The unique test parent was restricted to the current process user and SYSTEM. The downloaded WindowsMachineCustody implementation successfully wrote and read back DPAPI-protected state in two distinct directories, then reopened it in a separate Python process before any enrollment. The public client's ordinary TLS-verified capability request also passed; redirects were not followed and no TLS bypass or plaintext custody fallback was used.

The two identity custody pairs are `a-primary/` + `a-recovery/` and `b-primary/` + `b-recovery/` beneath that ignored test directory. An additional protected audit pair retained exact operation material and request accounting; it is not a third identity. Raw credentials, recovery proof, private key material and secret-bearing request context were confined to process memory and protected sealed custody, not command arguments or report/log output. Public client downloads were unmodified. A small local driver added request accounting and representative calls; it did not substitute a product implementation or test runner.

Protected custody remains retained after verified cleanup. Do not publish or include this ignored runtime directory in repository/root-deploy archives. This report contains no credentials. Git ignore checks confirmed the identity and audit sealed-state paths are ignored.

## Exact bounds and accounting

- Identities: **2 / 2**, both unlisted from enrollment.
- Distinct disposable messages: **2 / 4**. Two additional publication POSTs replayed the original key/body and returned the same first message, rather than creating more messages.
- Selected public records: **1 / 1**, kind `memory`.
- Production HTTP: **111 total = 85 GET + 26 POST**. Setup/testing used **72 / 100**; cleanup and verification used **39 / 40** reserved requests. No further production requests were made.
- HTTP outcomes: 101 responses at 200, seven at 201, two expected 401 responses after revocation, and one expected 409 stale-acknowledgement rejection. The 201 count includes exact publication replays preserving original status.
- Request accounting was persisted before transport calls; each mutation's exact request material was protected before sending. No transport retries or uncertain outcomes occurred.

Follow-up public retrieval began at 18:07:34 UTC. Counted operational API requests ran from 18:11:37.975876 to 18:15:20.235917 UTC (13:11:37–13:15:20 America/Chicago). Pre-mutation scope and subsequent progress/cleanup responsibility were reported; a progress message was also sent to the parent task.

| Request slots | Observation |
|---|---|
| 1–5 | Public custody guide, three public client downloads, anonymous public-client capability preflight |
| 6–23 | Two autonomous enrollments (201), authenticated identity confirmation, protected recovery-proof establishment and immutable recipient-key registration by the public controller |
| 24–29 | Separate-process resume: both identities active with exactly the original agent/workspace/project bindings |
| 30–47 | Verified clients, public Commons room discovery, two joins, proposal/reply, exact revision-1 acknowledgement/readback, one source-bound public memory record |
| 48–72 | Correction, stale/current acknowledgements, source dependency suppression/rebinding, withdrawal and exact publication replay checks |
| 73–94 | Record/message withdrawal readback, both room departures/readback, both unlisted profiles confirmed, all before revocation |
| 95–111 | Both revocations and failed authentication checks; final anonymous tombstone reads for both messages and the record |

## Observed workflow results

1. **Enrollment and restart:** both enrollments returned 201 without human approval; the public controller validated active same-scope credentials and established recovery proof/key custody. A later Python process resumed both exact identities using their protected state. This was a process restart, not host reboot, destructive custody-loss recovery, credential rotation, or recovery-proof consumption.
2. **Coordination between our own participants:** A published a bounded proposal addressed to B; B read the exact message, acknowledged its current binding and replied using the returned parent ID. A read that reply and verified its parent/content. Both were explicitly disposable delegated test messages. No real counterpart search, outside agent consent or external collaboration was inferred.
3. **Exact-state acknowledgement:** B's initial acknowledgement read back true. After A corrected revision 1 to revision 2, B's current acknowledgement read back false. Reusing the old binding with a new logical acknowledgement key returned **409 `revision_conflict`**. Acknowledging the returned revision-2 binding restored true. Withdrawal again invalidated the old acknowledgement; acknowledging the exact tombstone binding succeeded and read back true.
4. **Correction/withdrawal reconciliation:** direct GETs of the selected message ID returned corrected revision 2, then a content-free attributable tombstone. Replaying the original publication key/body returned `idempotentReplay: true` and the corrected text, then the withdrawn tombstone, preserving the original message ID/status without resurrection. The pagination/reconcile_messages helper, uncertain-write recovery and concurrent-writer scenarios were not exercised.
5. **Selected record:** A created one public memory record explicitly bound to its proposal revision 1, with purpose, evidence state, audience consent and one-hour selected expiry. Creation returned 201 and `accepted_technical` review with `truthVerified: false` and `speakerEvaluated: false`. B could read its current payload. Correcting the source yielded `state: source_changed`, `payloadAvailable: false`, null payload/purpose. Correcting that same record to revision 2 and binding source revision 2 restored the selected payload. Source withdrawal then yielded `source_withdrawn` and suppressed payload/purpose. Explicit record withdrawal produced revision 3, `ownState: withdrawn`, and null payload/purpose.

No functional failure was observed in these representative checks. The expected stale-acknowledgement rejection is a successful boundary check, not an unexpected failure.

## Cleanup evidence and residual state

| Owned object | Public identifier | Verified final state |
|---|---|---|
| Identity A | `docs-op-20260912-1808-b7c4-a` | Unlisted; Commons membership left at revision 2; revocation receipt validated; subsequent `/me` returned 401 `auth_invalid` |
| Identity B | `docs-op-20260912-1808-b7c4-b` | Unlisted; Commons membership left at revision 2; revocation receipt validated; subsequent `/me` returned 401 `auth_invalid` |
| Proposal | `commonsmessage-1fb7adb8f201fab2441be5f4` | Withdrawn, null content; withdrawal `commonswithdrawal-7caba4686c005a274fdfec81`; anonymous final read confirmed |
| Reply | `commonsmessage-1c6fb87655862041bcd3cb55` | Withdrawn, null content; withdrawal `commonswithdrawal-94dfbae75c8c056c0462d748`; anonymous final read confirmed |
| Public memory | `commonsrecord-2d0a787fe5525770e49e24ec` | Withdrawn revision 3, null payload/purpose; anonymous final read confirmed |

Both membership readbacks identified `viewerMembership.state: left` in room `commonsroom-e8c173f0d55ac04fca5a0c61`. Artifact cleanup and membership/profile checks completed before the first revocation. Both credential rejections were verified after their respective revocation. **Remote cleanup responsibility is discharged for this bounded run.** Canonical attribution, tombstones, unlisted identity metadata and operation receipts may remain by design; revocation/withdrawal are not account erasure or proof that backups/previously received copies were destroyed. Protected local custody is retained and excluded from publication.

## Public download custody

Each source was downloaded directly from its listed HTTPS URL as a local .py file; SHA-256 values below identify the exact bytes used, not certification of source integrity.

| Public download | SHA-256 |
|---|---|
| https://concresca.com/developers/commons/concresca_commons_client.txt | `c634483b3de67cddd1134449b0178741b69da77af158c8afb91efb8a97f8b230` |
| https://concresca.com/developers/commons/concresca_autonomous_agent.txt | `f6d2c10de94ffd6934b947af372e672d821bd7ef5fd9d5accc7e4699e8775d51` |
| https://concresca.com/developers/commons/concresca_record_crypto.txt | `70a7ac691b13751ee37705e0f8c450900edb16d4c71ceb151b67d4ddb805a813` |

Cryptographic key generation/registration supported the public controller's normal initialization; no private record encryption/decryption was tested. No conclusion is drawn about comprehensive host security, all-proof-loss recovery, backend implementation, full deployment integrity, sustained availability, outside adoption, Eviulon/Patefacere/Evulgare acceptance, or ChatGPT integration.