# Public Contribution Log This log tracks public work Mary Wang has done in other communities. It is not a testimonial list and does not claim revenue. ## 2026-05-24: AI Audit Shelf docs PR Link: https://github.com/ATHARVA262005/ai-audit-shelf/pull/19 Status: merged Merged PR: https://github.com/ATHARVA262005/ai-audit-shelf/pull/19 Maintainer response: `LGTM!` Follow-up: Maintainer requested a retrospective CLA signature on 2026-05-28. This requires human review and cannot be accepted by Mary/Codex. Context: - Mary commented on an open contributor issue about AI audit UX. - The maintainer replied and invited a docs PR. - Mary submitted an operator-facing guide explaining AI audit trails for non-technical users. Why it matters: - This is a real public interaction, not a fake case study. - It shows the Mary Wang positioning in practice: translating AI workflow infrastructure into plain-language operator guidance. - It is now a stronger proof asset because the PR was merged. Next follow-up: - Watch for follow-up issues or related docs requests. - Ask the account owner to review the CLA request before responding to it. - Use this as a public proof asset in relevant GitHub/community replies. - Do not present it as a paid client, testimonial, or revenue. ## 2026-06-05: Audit artifact schema comments Links: - https://github.com/victorlavrenko/answer-engineering/issues/19#issuecomment-4627493276 - https://github.com/coastalgit/solution-os/issues/27#issuecomment-4627494398 - https://github.com/dativo-io/talon/issues/147#issuecomment-4630401788 Status: public comments posted Context: - Both issues ask for machine-readable audit artifacts or governance audit output. - The later Talon issue asks for high-risk runtime tool calls to pass through HITL approval and signed evidence. - Mary replied with concrete schema fields, fixture tests, redaction checks, operator-facing warning classes, and approval-gate evidence records. Why it matters: - These comments show the narrowed Mary Wang wedge after the 14-day pivot: audit artifacts, review gates, and workflow handoff contracts. - They are useful public proof even if they do not become paid leads. Next follow-up: - Watch for maintainer replies after 24-72 hours. - If a maintainer asks for help, qualify the real workflow before mentioning the RMB 699 audit. ## 2026-06-06: Review-gated audit evidence comments Links: - https://github.com/oscharko-dev/Keiko/issues/536#issuecomment-4638198966 - https://github.com/ManicodeSecurity/trust-me-bro/issues/31#issuecomment-4638199606 Status: public comments posted Context: - One issue asks for a redacted audit/evidence/activity-state model. - One issue asks for review-gated vs auto-file scanner behavior while preserving audit/refutation evidence. - Mary replied with durable/transient state boundaries, evidence reference fields, and output separation invariants. Why it matters: - These comments strengthen the narrowed Mary Wang positioning around review-gated evidence, not generic AI workflow automation. - They are useful public proof but are not paid clients, testimonials, or revenue. Next follow-up: - Watch for maintainer replies by 2026-06-09. - If either maintainer engages, ask whether a small sample event model or artifact review would help before mentioning the paid audit. Follow-up result: - `Keiko#536` maintainer replied that the model was integrated via merged PR #572. - This is a public proof signal, not a paid client, testimonial, or revenue. ## 2026-06-07: Buyer-facing evidence pack and audit-log comments Links: - https://github.com/writer/aperio/issues/49#issuecomment-4642149291 - https://github.com/steffenboe/NclaveOS/issues/18#issuecomment-4642150327 Status: public comments posted Context: - One issue asks for auditor-ready evidence packs mapped to compliance frameworks. - One issue asks for approval-aware command audit logs. - Mary replied with concrete pack manifests, redaction boundaries, incomplete-evidence tests, and separate policy/approval/execution audit events. Why it matters: - These issues are closer to a buyer-facing pain: proving evidence to auditors and admins. - They strengthen the current offer around Audit Artifact Review instead of generic automation advice. Next follow-up: - Watch for maintainer replies by 2026-06-10. - If either maintainer engages, ask for one sample evidence pack or audit event shape before mentioning the paid audit. ## 2026-06-08: Talon evidence model adopted publicly Link: - https://github.com/dativo-io/talon/issues/147#issuecomment-4642447896 Status: maintainer incorporated Mary's suggestion into updated implementation expectations Context: - Mary suggested separating blocked runtime tool-call evidence from human approval decision evidence. - The Talon maintainer credited Mary and added the two linked signed evidence records to the issue's implementation expectation and acceptance criteria. Why it matters: - This is the strongest current public proof for the Audit Artifact Review wedge. - It shows that Mary's comments are not just visible; they can shape maintainers' audit/evidence specs. - It is still not a paid client, testimonial, or revenue. Next follow-up: - Watch whether Talon creates a follow-up issue or sample export. - If a sample export appears, ask to sanity-check the lifecycle boundary before mentioning the paid audit. ## 2026-06-08: Signed audit export comment Link: - https://github.com/DariuszNewecki/CORE/issues/525#issuecomment-4647742172 Status: public comment posted Context: - The CORE issue is a signed cloud audit export aimed at Solo-tier commercial revenue. - Mary replied with a minimum signed export pack and a negative fixture for missing or mismatched evidence references. Why it matters: - This is a commercial-audit-export lead, closer to paid work than broad automation discussion. - It reinforces Mary Wang's narrowed positioning around audit artifacts that buyers can actually inspect. Follow-up result: - The issue owner accepted the core shape and clarified the F-46 boundary as buyer-readable audit evidence, not governed-change evidence. - Mary posted a follow-up fixture matrix for verifier completeness: - https://github.com/DariuszNewecki/CORE/issues/525#issuecomment-4658665372 - This is an engaged public lead, not a paid client or testimonial. ## 2026-06-09: Rust-native signed audit verifier comment Link: - https://github.com/MonikaDvorackova/govai-core/issues/31#issuecomment-4658672865 Status: public comment posted Context: - The issue asks for Rust-native verification of signed GovAI Core audit exports. - Mary replied with a staged verifier result model and negative fixtures for signed-but-incomplete evidence packages. Why it matters: - This is a direct match for the Audit Artifact Review wedge: signed exports, verifier behavior, and buyer/auditor usefulness. - It gives Mary another public example in the narrower signed audit export niche without making a sales pitch. Next follow-up: - Watch for maintainer reply by 2026-06-12. - If a sample export format appears, ask whether a short artifact sanity check would help. ## 2026-06-09: Runtime evidence manifest comment Link: - https://github.com/oscharko-dev/Keiko/issues/484#issuecomment-4658673104 Status: public comment posted Context: - The issue asks for runtime credential separation, redaction, evidence manifests, policy outcomes, and operator-safe diagnostics. - Mary replied with an operator-facing manifest structure and negative tests for credential leakage, degraded execution, redaction timing, and policy-denial recording. Why it matters: - The same repo previously integrated a Mary suggestion into a merged PR, so this is a good repeat-context channel. - The advice supports the current Mary positioning around evidence artifacts security operators can actually review. Next follow-up: - Watch for maintainer engagement by 2026-06-12. - If they engage, qualify around the current evidence manifest schema before mentioning any paid audit. ## 2026-06-10: CORE verifier contract adopted into ADR/enum work Links: - Owner response: https://github.com/DariuszNewecki/CORE/issues/525#issuecomment-4660576732 - Owner ADR/enum update: https://github.com/DariuszNewecki/CORE/issues/525#issuecomment-4660752875 - Mary follow-up: https://github.com/DariuszNewecki/CORE/issues/525#issuecomment-4668938965 Status: maintainer adopted Mary's verifier contract direction into project artifacts Context: - Mary suggested that F-46 signed exports need a buyer-readable verifier contract and a strict F-46/F-37 boundary. - The owner converted the boundary into `export_evidence_class` with `audit_evidence` and `governed_change_evidence`. - Mary followed up by asking for a tiny synthetic fixture export skeleton as the next artifact. Why it matters: - This is the closest current public proof for the `Audit Artifact Review` wedge. - It shows that Mary can shape real audit-export product semantics, not just leave generic advice. - It is still not a paid client, testimonial, or revenue. Next follow-up: - Watch for an export skeleton or fixture by 2026-06-13. - If a sample appears, ask to sanity-check it against the verifier boundary before mentioning the paid audit. ## 2026-06-10: CI audit evidence bundle comment Link: - https://github.com/blencorp/ashlar/issues/11#issuecomment-4668939425 Status: public comment posted Context: - The issue asks to harden CI for audit, verify, evidence validation, artifact upload, and SARIF output. - Mary replied with a single uploaded evidence bundle shape and a verifier-vs-SARIF boundary. Why it matters: - This is a direct match for buyers who need proof artifacts from CI rather than another dashboard. - It reinforces Mary as an operator who turns audit workflows into inspectable artifacts. Next follow-up: - Watch for maintainer reply by 2026-06-13. - If the maintainer describes the current artifact format, qualify around missing bundle/verifier fields. ## 2026-06-10: Proof packet schema comment Link: - https://github.com/euphoricdoom/.Neon/issues/28#issuecomment-4668939823 Status: public comment posted Context: - The issue asks for a portable proof packet format for audit bundles. - Mary replied with a facts/claims/limits manifest shape and a negative unsupported-rights-claim fixture. Why it matters: - Proof packet structure is adjacent to the paid audit offer: customers need artifacts that are verifiable and honest about limits. - The comment strengthens Mary's public proof around audit packets, redaction, verifier output, and non-claims. Next follow-up: - Watch for maintainer reply by 2026-06-13. - If they engage, ask for the first sample packet or verifier report before any paid audit pitch. ## 2026-06-11: CORE fixture boundary follow-up Link: - https://github.com/DariuszNewecki/CORE/issues/525#issuecomment-4676522556 Status: public follow-up posted after maintainer engagement Context: - The CORE owner agreed with the fixture-first path and refined subject reference shape plus verifier error vocabulary. - Mary followed up by separating the immediate fixture bench from the deferred context-summary ADR and proposed a `governed_change_leak` canary. Why it matters: - This keeps the strongest current lead moving toward a concrete sample export or fixture bench. - It is the most likely path to a qualified lead because the discussion is now about a specific artifact boundary, not abstract positioning. - It is still not a paid client, testimonial, or revenue. Next follow-up: - Watch for a fixture export, bench skeleton, or follow-up ADR by 2026-06-14. - If a concrete artifact appears, offer a concise artifact sanity check and prepare the RMB 699 audit offer. ## 2026-06-11: Redaction-safe evidence bundle comment Link: - https://github.com/madmax983/egregore/issues/68#issuecomment-4676526612 Status: public comment posted Context: - The issue asks for local, redaction-safe evidence bundle exports from an evidence graph. - Mary replied with separate verifier verdicts for integrity, coverage, and safety, plus negative fixtures for protected payload leakage and incomplete evidence closure. Why it matters: - This directly matches the Audit Artifact Review wedge: evidence handoff, redaction, verifier output, and reviewability. - It broadens Mary beyond signed exports into local-first evidence packaging. Next follow-up: - Watch for maintainer reply by 2026-06-14. - If they engage, ask for a sample bundle or verifier-result shape. ## 2026-06-11: Portable offline verifier comment Link: - https://github.com/safal207/ProofPath/issues/161#issuecomment-4676526780 Status: public comment posted Context: - The issue asks for portable, tamper-evident payment-guard evidence and an offline verifier. - Mary replied with a small bundle layout and deterministic fixtures for tamper detection and privacy-boundary failure. Why it matters: - Offline verification is a strong buyer-facing audit story: prove decisions without trusting a live service. - The issue is grant/reviewer oriented, which fits Mary Wang's current evidence-artifact positioning. Next follow-up: - Watch for maintainer reply by 2026-06-14. - If they provide a first fixture direction, qualify around first bundle format before any paid audit pitch. ## 2026-06-12: Keiko governed handoff audit follow-up shipped Links: - Maintainer closure evidence: https://github.com/oscharko-dev/Keiko/issues/186#issuecomment-4680470980 - Mary follow-up: https://github.com/oscharko-dev/Keiko/issues/186#issuecomment-4686677122 Status: maintainer reported audit follow-up shipped via PR #947 Context: - Mary previously suggested separating human approval, agent execution, patch scope, read-only evidence, unknowns, required checks, and closure evidence. - The maintainer later reported PR #947 shipped audit follow-up work and preserved governed handoff provenance in evidence manifests. - Mary followed up with a narrow remembered-context evidence-reference model for any future design. Why it matters: - This is the second strong public proof signal after `Talon#147` and `CORE#525`. - It shows Mary's artifact/audit advice can map to merged implementation evidence. - It is still not a paid client, testimonial, or revenue. Next follow-up: - Do not pitch the audit offer on this closed issue. - Watch for related Keiko follow-up issues around remembered context, evidence manifests, or workflow handoff. ## 2026-06-12: Vulnerability evidence-bundle provenance comment Link: - https://github.com/Noetheon/vuln-prioritizer-cli/issues/29#issuecomment-4686677236 Status: public comment posted Context: - The issue asks for interactive HTML reporting and stronger evidence-bundle provenance metadata. - Mary replied with a separation between HTML reviewer navigation, machine-readable evidence bundle, and verifier result. Why it matters: - Vulnerability prioritization is a buyer-facing domain where evidence provenance matters. - The comment applies Mary's current wedge to a practical offline reporting workflow. Next follow-up: - Watch for maintainer reply by 2026-06-15. - If they share a manifest shape or example report, qualify around an artifact sanity check. ## 2026-06-12: Signed gate-evidence bundle comment Link: - https://github.com/piyushgupta27/ai-sdlc/issues/86#issuecomment-4686677367 Status: public comment posted Context: - The issue asks for per-PR signed gate evidence and a verifier required by branch protection. - Mary replied with a concrete bundle layout and negative fixtures that check both signature and gate semantics. Why it matters: - This fits the signed evidence/verifier niche that has been getting better engagement than general automation. - Required status checks are a concrete operational buyer problem: what evidence can a human trust before merge? Next follow-up: - Watch for maintainer reply by 2026-06-15. - If they engage, qualify around the first bundle/verifier contract before any paid audit pitch. ## 2026-06-13: CORE evidence-class boundary follow-up Link: - https://github.com/DariuszNewecki/CORE/issues/525#issuecomment-4697097031 Status: engaged follow-up posted Context: - The owner clarified that ADR-100 already owns the F-46/F-37 evidence-class boundary. - Mary replied by narrowing the next useful artifact to fixture behavior: an `audit_evidence` export should fail if it contains governed-change chain semantics. Why it matters: - This keeps the closest current lead moving toward a concrete verifier fixture instead of abstract strategy. - It is still not a qualified lead because no export skeleton, manifest, fixture, or verifier output has been shared. Next follow-up: - Watch for a first ExportManifest contract, fixture bench, or verifier error vocabulary by 2026-06-16. - If a sample appears, ask whether a short outside artifact review would be useful before mentioning price. ## 2026-06-13: Signed audit export log redaction comment Link: - https://github.com/fermano/TC2/issues/90#issuecomment-4697103924 Status: public comment posted Context: - The issue reports signed audit export query parameters being persisted in debug logs during upstream `502` delivery failures. - Mary replied with a persistence-boundary fix point and a regression test that checks durable stored logs, not only the diagnostic view. Why it matters: - This is a practical audit-export safety problem: the artifact may be signed correctly while operational logs leak access material. - It extends the wedge from bundle/verifier structure into audit-export delivery hygiene. Next follow-up: - Watch for maintainer reply by 2026-06-16. - Do not comment on the duplicate TC1/TC3/TC4 issues unless explicitly invited. ## 2026-06-13: Egregore complete JSONL export boundary comment Link: - https://github.com/madmax983/egregore/issues/155#issuecomment-4697103926 Status: public comment posted Context: - The issue asks for full embedded-store export back to canonical JSONL for backup, migration, and round-trip proof. - Mary replied by separating complete store backup exports from redaction-safe evidence bundles. Why it matters: - This boundary is important for non-technical operators: "complete backup" is not automatically safe public evidence. - It fits the artifact-review offer because a buyer may need someone to classify what can be shared and what must stay private. Next follow-up: - Watch for maintainer reply by 2026-06-16. - If they discuss manifest shape or private-payload classes, qualify around a sample export safety review. ## 2026-06-13: Upkeeper sanitized JSONL identity comment Link: - https://github.com/joeszilagyi/Upkeeper/issues/661#issuecomment-4697103923 Status: public comment posted Context: - The issue reports a possible `table:None` logical-key collapse when sanitized JSONL payloads lose primary-key fields before import conflict handling. - Mary replied with explicit identity cases and a regression fixture where two distinct sanitized rows must not collapse into one logical conflict key. Why it matters: - This is a data-integrity audit example, adjacent to the evidence-export wedge. - It shows Mary can review not only signatures and manifests, but also whether sanitized artifacts preserve enough identity to support reliable import/conflict decisions. Next follow-up: - Watch for maintainer reply by 2026-06-16. - If a fixture or importer behavior question appears, qualify around artifact sanity checking. ## 2026-06-14: GovAI Core structured verifier result follow-up Link: - https://github.com/MonikaDvorackova/govai-core/issues/31#issuecomment-4700407598 Status: maintainer engaged; Mary follow-up posted Context: - The maintainer proposed a Rust `VerificationResult` with staged verification fields and an overall verdict. - Mary replied with stable machine-readable reason codes, stage status separation, and fixture-per-code serialized output snapshots. Why it matters: - This is a high-fit engaged lead for the signed audit verifier wedge. - It moves from broad advice into a concrete API contract discussion. - It is still not a qualified lead because no sample bundle, manifest, or verifier output has been shared. Next follow-up: - Watch for schema/fixture updates by 2026-06-17. - If a serialized `VerificationResult` or fixture appears, ask whether a short outside artifact review would help before mentioning price. ## 2026-06-14: Verification and defamation publish-gate comment Link: - https://github.com/benseverndev-oss/goldenmatch-shell-company-network/issues/160#issuecomment-4700411308 Status: public comment posted Context: - The issue asks for evidence bundles, primary-source deep links, and a verification/defamation checklist before publishing leads. - Mary replied with a machine-readable dossier and `publish_gate` status record, plus negative fixtures for unreachable sources, unsupported claims, and checklist mismatch. Why it matters: - This is a sensitive public-evidence workflow where artifact boundaries matter. - It fits Mary's review position: make evidence reviewable before publication, not just visually documented. Next follow-up: - Watch for maintainer reply by 2026-06-17. - Qualify only if they share a dossier schema, checklist output, or publish gate artifact. ## 2026-06-14: Reviewer-ready export DoD comment Link: - https://github.com/fderuiter/CRF.xl/issues/56#issuecomment-4700411295 Status: public comment posted Context: - The issue is a reviewer-ready export epic and GitHub Actions flagged that an Evidence Required / Definition of Done section is missing. - Mary replied with an export manifest, verification report, regeneration rule, blocker rule, and mismatched-hash negative fixture. Why it matters: - Reviewer package completeness is a clear audit-artifact problem. - This expands the wedge beyond security repos into document/reviewer workflow exports. Next follow-up: - Watch for maintainer reply by 2026-06-17. - If a reviewer package or verification report format appears, qualify around an artifact sanity check. ## 2026-06-14: Robinhood MCP credential redaction comment Link: - https://github.com/quantam101/tradegate2/issues/10#issuecomment-4700411296 Status: public comment posted Context: - The issue asks for scanner/runtime/UI/audit-log redaction for private brokerage identifiers and connection secrets. - Mary replied with durable-boundary redaction tests, stored-log assertions, nested payload fixtures, and keyed digest/surrogate guidance. Why it matters: - Financial identifiers are high-sensitivity artifacts. - This is a practical example of making audit logs useful without leaking private account material. Next follow-up: - Watch for maintainer reply by 2026-06-17. - If they share an event schema or redaction fixture, qualify around artifact-safety review. ## 2026-06-14: Audit log redaction hardening comment Link: - https://github.com/jovillal/placamia/issues/67#issuecomment-4700411293 Status: public comment posted Context: - The issue asks to harden audit logging redaction beyond sensitive key names and document role handling. - Mary replied with key-based and value-shape redaction layers, reason tags, and a nested regression fixture. Why it matters: - This is a moderate-fit audit artifact safety example. - It reinforces Mary's pattern: make redaction testable at the stored artifact layer, not only in presentation. Next follow-up: - Watch for maintainer reply by 2026-06-17. - Qualify only if they share the current audit log policy or fixture structure. ## 2026-06-15: GovAI Core contribution scope follow-up Link: - https://github.com/MonikaDvorackova/govai-core/issues/31#issuecomment-4703914279 Status: maintainer invited contribution; Mary replied with narrow contribution scope Context: - The maintainer asked whether Mary would contribute part of the `VerificationResult` model, reason-code taxonomy, or fixture structure. - Mary replied that a small contract-first PR would be appropriate, preferably fixture contract first unless the Rust type location is already settled. Why it matters: - This is the clearest direct invitation so far for Mary to contribute to a real verifier contract. - It is not revenue yet, but it is strong public proof for the audit artifact review wedge. Next follow-up: - Watch for maintainer preference by 2026-06-18. - If they identify a concrete module or fixture path, decide whether to open a small PR or ask for a sample artifact review scope. ## 2026-06-15: ProofPath evidence bundle fixture PR Links: - PR: https://github.com/safal207/ProofPath/pull/164 - Issue follow-up: https://github.com/safal207/ProofPath/issues/161#issuecomment-4703913376 Status: public PR opened from Mary fork Context: - The maintainer accepted the v0.1 offline evidence bundle direction and proposed adding a fixture directory plus README reviewer flow. - Mary opened a narrow docs/fixture-contract PR adding `fixtures/evidence-bundle-v0.1/README.md`. Why it matters: - This is a concrete public contribution beyond comments. - It demonstrates Mary can turn an audit-verifier discussion into a reviewable artifact without overclaiming implementation completeness. - It is still not a paid client, testimonial, or revenue. Next follow-up: - Watch PR #164 for review by 2026-06-18. - If accepted, record it as public proof; if maintainer asks for actual sample fixtures, keep scope narrow and avoid giving away a full paid audit package unless it clearly advances conversion. ## 2026-06-15: PDF signature verifier result-state comment Link: - https://github.com/marctjones/pdfe/issues/466#issuecomment-4703918179 Status: public comment posted Context: - The issue asks for signature trust-chain validation and clearer result states, including ByteRange/CMS integrity, certificate trust, and document modification state. - Mary replied with a structured result model, first-class `unknown` trust handling, and fixture snapshots for both verifier state and UI phrase. Why it matters: - It is a strong example of Mary reducing audit overclaim risk: a valid low-level signature is not the same as trusted signer status. - The topic maps directly to buyer-facing verifier result reviews. Next follow-up: - Watch for maintainer reply by 2026-06-18. - If result models or fixture examples appear, qualify around a short verifier-result sanity review. ## 2026-06-15: MCP orchestration redaction boundary comment Link: - https://github.com/equaltoai/lesser-body/issues/332#issuecomment-4703918181 Status: public comment posted Context: - The issue asks to verify that instance keys, JWTs, and bearer tokens never appear in orchestration tool results or audit logs. - Mary replied with separate assertions for caller-facing `toolJSONResult()` and durable audit/log output, plus nested secret leak fixtures. Why it matters: - This keeps the redaction wedge focused on artifact boundaries, not cosmetic output cleanup. - It is a practical operator trust problem in MCP-style tool orchestration. Next follow-up: - Watch for maintainer reply by 2026-06-18. - If they share handler/test structure, qualify around audit-output redaction review. ## 2026-06-16: ProofPath fixture contract merged Link: - https://github.com/safal207/ProofPath/pull/164 Status: merged public PR Context: - Mary opened a docs-only fixture contract for the ProofPath v0.1 offline evidence bundle. - The maintainer reviewed it as the right first-pass contract and merged it. Why it matters: - This is the strongest public proof so far: a maintainer accepted a Mary-authored audit artifact contract. - It shows Mary can convert a verifier discussion into a merged, bounded artifact without fake data or implementation overclaims. - It is still not a paid client, testimonial, or revenue. Next follow-up: - Watch related ProofPath follow-up issue #165 by 2026-06-19. - Do not expand into full implementation unless it clearly supports conversion or a scoped paid artifact review. ## 2026-06-16: GovAI Core audit verifier fixture contract PR Links: - PR: https://github.com/MonikaDvorackova/govai-core/pull/108 - Issue follow-up: https://github.com/MonikaDvorackova/govai-core/issues/31#issuecomment-4714173807 Status: public PR opened from Mary fork Context: - The maintainer asked for fixture contract first, before Rust verifier types. - Mary opened a docs-only PR defining reason codes, staged result expectations, fixture matrix, and serialized output invariants. Why it matters: - This is a second PR-level proof asset in the same audit-verifier wedge. - It further narrows Mary's strongest public identity: verifier/result contract reviewer for audit exports. Next follow-up: - Watch PR #108 for review by 2026-06-19. - If accepted, record as public proof; if requested changes appear, address them narrowly. ## 2026-06-16: Rava production audit export boundary comment Link: - https://github.com/syndicalt/rava/issues/122#issuecomment-4714178050 Status: public comment posted Context: - The issue tracks production audit storage, retention, export, tamper evidence, legal hold, and sensitive-payload boundaries. - Mary replied with an `export_manifest.json` shape and a negative fixture where raw sensitive payload dependency fails production-readiness review. Why it matters: - Production audit export is close to a buyer-facing artifact review problem. - The comment emphasizes clear non-claims: local preview export is not managed production audit storage. Next follow-up: - Watch for maintainer reply by 2026-06-19. - If they share an export manifest or test evidence, qualify around an artifact review. ## 2026-06-16: igentic typed policy reason-code comment Link: - https://github.com/pokekarten/igentic-iphone/issues/13#issuecomment-4714178043 Status: public comment posted Context: - The issue asks for typed policy decision reason codes so policy behavior is easier to test, audit, and document. - Mary replied with a stable decision/reason/message/evidence shape and smoke tests for important policy paths. Why it matters: - This is a smaller but clean verifier-contract example. - It reinforces Mary's emphasis on stable result codes instead of fragile prose parsing. Next follow-up: - Watch for maintainer reply by 2026-06-19. - Qualify only if they ask for help with serialization, fixture design, or policy result review. ## 2026-06-17: agent-bom hosted evidence lake comment Link: - https://github.com/msaad00/agent-bom/issues/2929#issuecomment-4725253357 Status: public comment posted Context: - The issue proposes a hosted evidence lake for retained graph history, cross-scan diffing, audit chain, and compliance evidence bundles. - Mary replied with a boundary between the query store and exported evidence bundle, including tenant isolation, source snapshot, graph/finding digests, retention policy, legal hold, redaction class, and manifest verification. Why it matters: - This is a strong SaaS/compliance-adjacent version of the Audit Artifact Review offer. - It moves Mary's proof base from issue-level advice toward buyer-relevant evidence architecture: retained history that can be trusted, compared, and exported. Next follow-up: - Watch for maintainer reply by 2026-06-20. - If they share a sample manifest, export shape, or evidence lake contract, qualify for paid artifact review. ## 2026-06-17: UIW compliance evidence automation comment Link: - https://github.com/voltron-1/UIW-Cyber-Defence-Platform/issues/82#issuecomment-4725257625 Status: public comment posted Context: - The issue asks for compliance evidence automation where Sigma rules and SOP metadata generate CISO report coverage. - Mary replied with a fail-closed metadata contract, visible coverage denominator, unmapped IDs, invalid-ID handling, deprecated artifact handling, and no-demo-fallback tests. Why it matters: - This is directly tied to compliance report evidence, not generic AI workflow cleanup. - It gives Mary another public example of turning an ambiguous report requirement into an auditable artifact contract. Next follow-up: - Watch for maintainer reply by 2026-06-20. - If they provide sample rule/SOP metadata or ask for report artifact review, qualify and send the Audit Artifact Review scope email. ## 2026-06-18: pdfe signature trust validation follow-up Link: - https://github.com/marctjones/pdfe/issues/466#issuecomment-4737175012 Status: engaged follow-up posted Context: - The maintainer clarified that the current release does not claim OS/certificate-chain trust validation and that README/CHANGELOG document the limitation. - Mary replied with a trust-state acceptance matrix and a UI invariant: stronger trust language should only appear when certificate-chain trust is explicitly `trusted`. Why it matters: - This is a clean example of Mary turning a release limitation into a testable product-safety contract. - It reinforces the Audit Artifact Review wedge around verifier result states and overclaim prevention. Next follow-up: - Watch for fixture/result-model discussion by 2026-06-21. - Qualify only if a concrete result model, fixture, or review artifact is shared. ## 2026-06-18: sportsml SOC2 readiness comment Link: - https://github.com/walter-robson/sportsml/issues/31#issuecomment-4737180945 Status: public comment posted Context: - The issue says SOC2 is a deal-blocker for NBA enterprise sales and asks about vendor selection, control mapping, evidence automation, and Type I vs Type II. - Mary replied with a practical control/evidence inventory shape and a sequence: prove control design and evidence sources first, then build operating history. Why it matters: - This is one of the clearest commercial-intent leads so far because the issue ties compliance evidence directly to sales. - It keeps Mary out of certification claims while showing useful artifact-operator judgment. Next follow-up: - Watch for owner reply by 2026-06-21. - If they share a control matrix, evidence list, or readiness artifact, qualify for Audit Artifact Review. ## 2026-06-18: Agent Armor audit-evidence package comment Link: - https://github.com/stylusnexus/agent-armor/issues/24#issuecomment-4737182178 Status: public comment posted Context: - The issue proposes diagnostics callbacks and durable audit-evidence records for agent scans. - Mary replied by separating event record, evidence package, and control claim, then suggested package digest and no-raw-content/tamper reconciliation tests. Why it matters: - This is highly aligned with the audit artifact wedge: agent systems need durable proof without leaking raw content. - It provides a reusable public proof example for evidence package design. Next follow-up: - Watch for maintainer reply by 2026-06-21. - If they share an audit record/export sample or ask for package review, qualify. ## 2026-06-19: GovAI Core PR workflow repair Link: - https://github.com/MonikaDvorackova/govai-core/pull/108#issuecomment-4747787668 Status: PR updated after maintainer review Context: - The maintainer said the fixture-contract direction is valuable and aligned with the verifier roadmap. - The PR could not be merged because it targeted the wrong branch and lacked the required repository workflow artifacts. - Mary rebased the branch onto current `staging`, changed the PR base to `staging`, added `docs/reports/audit-export-verifier-fixture-contract.md`, force-pushed with lease, and replied with validation. Why it matters: - This turns a failed PR into a better public proof asset instead of abandoning it. - It demonstrates that Mary can follow an evidence-heavy contribution workflow, not just write useful comments. - It is still not a paid lead or endorsement. Validation: - `python scripts/gate_reports.py` - `git diff --check upstream/staging...HEAD` Next follow-up: - Watch PR #108 checks and review by 2026-06-22. - If the maintainer requests narrow changes, address them without expanding scope. ## 2026-06-19: Yuzu SOC2 control matrix comment Link: - https://github.com/Tr3kkR/Yuzu/issues/303#issuecomment-4747798112 Status: public comment posted Context: - The issue asks for a SOC2 control matrix and evidence index covering Security and Availability trust criteria. - Mary replied with a combined control matrix/evidence index row shape, evidence repository naming convention, freshness rules, and generated-governance-agent boundary. Why it matters: - This is a high-fit artifact problem: the buyer-shaped deliverable is a control/evidence index, not generic AI automation. - It reinforces the narrowed Audit Artifact Review wedge around compliance evidence artifacts. Next follow-up: - Watch for maintainer reply by 2026-06-22. - If they share a matrix draft or evidence index, qualify for Audit Artifact Review. ## 2026-06-20: GovAI Core CI log follow-up Link: - https://github.com/MonikaDvorackova/govai-core/pull/108#issuecomment-4756014785 Status: PR follow-up posted after maintainer asked for remote check investigation Context: - The maintainer asked Mary to inspect required GitHub Actions failures on PR #108. - Mary opened the available failing logs and found they came from the old PR event that still evaluated the PR as base `main`. - The current PR now targets `staging`, so Mary pushed empty trigger commit `cb16a10` to create a fresh PR event. - The new runs for `cb16a10` are `action_required`, and logs are not available yet. Why it matters: - This is public proof of operational follow-through, not just writing advice. - It shows Mary can distinguish stale CI failures from current content errors and avoid making unnecessary code changes. - It is still open-source proof only, not a paid client or endorsement. Validation: - `python scripts/gate_reports.py` - `git diff --check upstream/staging...HEAD` Next follow-up: - Wait for maintainer approval or fresh remote logs. - If the new checks run and fail, inspect exact logs before changing the PR. ## 2026-06-20: igentic policy reason-code acceptance Link: - https://github.com/pokekarten/igentic-iphone/issues/13 Status: issue closed by maintainer implementation after Mary's public comment Context: - Mary suggested a stable policy-decision shape with explicit reason codes and smoke tests. - The maintainer closed the issue through PR #48, adding typed `PolicyDecisionReason` coverage for local-only delegation blocking, restricted-data automation denial, cloud escalation blocking, tool unavailable, tool error, and success fallback. Why it matters: - This is another public proof point that Mary's artifact-contract suggestions can be implemented by maintainers. - It supports the narrowed positioning around reason-code contracts and verifier output clarity. - It is not a paid lead. Next follow-up: - Use this as proof when explaining reason-code review capability. - Do not pitch unless the maintainer asks for another artifact review. ## 2026-06-20: Talon academy AI audit evidence bundle comment Link: - https://github.com/dativo-io/talon-www/issues/31#issuecomment-4756017460 Status: public comment posted Context: - The issue is a buyer-facing academy page on preparing AI audit evidence bundles for CTOs, DPOs, founders, security leads, and sales engineering. - Mary replied with four reviewer questions, required evidence handoff README fields, and a raw-log-only negative example. Why it matters: - This is closer to the commercial buyer language than many low-level engineering issues. - It reinforces the Audit Artifact Review offer around concrete bundle structure, scope, evidence, limitations, and reviewer usability. Next follow-up: - Watch for maintainer reply by 2026-06-23. - Qualify only if they share a sample bundle, page draft, template, or review artifact. ## 2026-06-21: DevSecOps evidence bundle generator comment Link: - https://github.com/mason5052/production-kubernetes-devops-platform/issues/5#issuecomment-4760617023 Status: public comment posted Context: - The issue asks for an evidence bundle generator example covering deployment, scan, approval, and rollout records. - Mary replied with a concrete bundle folder layout, manifest schema, README requirements, sensitive-field exclusions, and verification tests. Why it matters: - This is directly aligned with the Audit Artifact Review offer: the buyer-shaped deliverable is a reviewable evidence package, not raw logs. - It demonstrates how Mary turns a broad DevSecOps evidence request into a concrete schema plus acceptance tests. Next follow-up: - Watch for maintainer reply by 2026-06-24. - Qualify only if they ask for schema review, example bundle, or generator implementation help. ## 2026-06-21: Domits Airbnb compliance evidence matrix comment Link: - https://github.com/domits1/Domits/issues/3090#issuecomment-4760617580 Status: public comment posted Context: - The issue describes an Airbnb certification and security compliance program with continuous evidence readiness. - Mary replied by recommending an evidence matrix before a dashboard, including a row shape, repository structure, readiness score guardrails, and a five-control evidence test. Why it matters: - This is a stronger commercial-context proof point because the issue is tied to API certification, partner trust, and recurring security reviews. - It supports Mary positioning around control/evidence matrices and customer-review readiness. Next follow-up: - Watch for maintainer reply by 2026-06-24. - Qualify if they share an evidence matrix, dashboard draft, or readiness artifact. ## 2026-06-22: GovAI Core fixture contract PR merged Link: - https://github.com/MonikaDvorackova/govai-core/pull/108 Status: merged public contribution Context: - Mary created and maintained PR #108 for the signed audit export verifier fixture contract. - The PR initially needed workflow repair: target `staging`, required audit report, and remote compliance/evidence-pack checks. - Mary rebased, added the required report, inspected stale base-`main` failures, triggered fresh checks, and waited for maintainer workflow approval. - On 2026-06-21, all required remote checks passed and the maintainer merged the PR. - The maintainer described the fixture contract as valuable for verifier standardization, compatibility testing, and future integration work, and invited follow-up implementation alignment in #110. Why it matters: - This is Mary's strongest public proof so far: a real maintainer reviewed and merged a scoped audit/verifier artifact contribution. - It demonstrates workflow follow-through, CI diagnosis, report-gate compliance, and artifact-contract thinking. - It is still not a paid client, testimonial, or revenue. Validation: - PR branch policy: success - compliance checks: success, including `report_gate`, `report_content`, `make_verify`, and `evidence_pack` - govai-ci: success - security-scan: success - supply-chain-audit: success Next follow-up: - Consider a follow-up PR for #110 only if it strengthens proof without displacing commercial outreach. - Use this as proof when explaining Audit Artifact Review capability. ## 2026-06-22: Talon AI traffic monitoring evidence-view comment Link: - https://github.com/dativo-io/talon-www/issues/27#issuecomment-4764089302 Status: public comment posted Context: - The issue is a buyer-education page about monitoring AI traffic in production. - Mary replied with a dashboard split for CTO summary, operator drill-down, and security/evidence view, plus sample alerts. Why it matters: - It connects observability to reviewable evidence, which is closer to the paid audit artifact positioning than generic monitoring advice. - It reinforces the distinction between fast operational dashboards and stable audit evidence exports. Next follow-up: - Watch for maintainer reply by 2026-06-25. - Qualify only if they ask for a dashboard spec, metrics checklist, or evidence export review. ## 2026-06-22: MedBrains multi-standard compliance dashboard comment Link: - https://github.com/DomnicAmalan/MedBrains/issues/1265#issuecomment-4764090131 Status: public comment posted Context: - The issue asks for a healthcare compliance dashboard across NABH, HIPAA, ISO, and CERT-In. - Mary replied with a reusable evidence row shape, Given/When/Then acceptance cases, RLS/PHI visibility guardrails, and strictest-framework freshness rule. Why it matters: - This is a strong fit for Mary because multi-standard dashboards often fail when evidence freshness, tenant scope, PHI exposure, and cross-framework reuse are not explicit. - It supports Mary positioning around compliance evidence matrix review. Next follow-up: - Watch for maintainer reply by 2026-06-25. - Qualify if they share dashboard schema, evidence matrix, or ask for artifact review.