Policy and governance · work samples
Five pieces of public work, in reading order, each with what it shows and what it does not.
Newark, NJ · g6llc@proton.me · ORCID 0009-0000-6496-2186 · github.com/TOTOGT
Everything below is public and can be checked. I list what each piece does not show next to what it does, so you do not have to find the limits yourself.
An open-access working paper on the governance of automated credit liquidation.
Shows: the interval between a system detecting a shortfall and taking an irreversible action treated as an auditable governance object, four proposed controls, and every claim tagged as documented, modeled, prospective or open.
Does not show: peer review. It is a working paper and is not peer-reviewed. It is about credit systems, not enterprise data.
The same paper read as an analyst would: each proposed control as a requirement, a test and a status, with one control run on the page.
Shows: turning a policy proposal into testable controls, with a worked check whose results were derived by hand first.
Does not show: use on a real system. The example numbers are invented, and the four tests are proposals made in the chapter.
The base working paper under the other two: why selling at a loss is not identified as a preference, and why small liquidity shortfalls cascade. It is Working Paper 32 in Book 6 of this series.
Shows: urgency defined as the shadow price on a liquidity constraint, which moves the diagnosis from the seller's preferences to the seller's balance sheet. That is the premise the response-gap controls rest on.
Does not show: peer review. It is a working paper published on this site and is not peer-reviewed.
A governance, ethical, legal and social implications paper on AI credit and an invisible wealth transfer, published openly on this site.
Shows: the same argument developed in the AI-credit setting, with each claim tagged by its status.
Does not show: peer review, or any test of its predictions on a deployed model.
Each page has a verification script, for example the one for the policy brief, and every change is recorded in a dated audit log. Each script is written before the page and is tested against negative controls, known-bad copies it must reject, to show it can fail.
Shows: version control, change records, and a habit of testing the test.
Does not show: that every claim on a page is true. The scripts check structure and stated facts, not whether a conclusion is right.
This is not data-privacy or data-protection experience. My formal experience is in records and compliance at schools and in credit governance at a bank, and I have not held a dedicated data-governance role. The work here is evidence of how I design and check governance material, and it is offered as that.