About · Archive
Selected work across digital trust, governance, evidence, decision framing, delivery and technology leadership.
This is not a product catalogue or complete career history. It preserves the context, decisions, methods and outcomes behind work carried across enterprise and independent settings.
The entries show the recurring discipline described in The Trust Practice. Names and implementation details are intentionally softened.
Work focused on the public and operational surfaces through which control, reliability and organisational posture become visible.
Designed and implemented a two-surface status model separating public trust communication from operational investigation, with monitoring-provider output treated as input rather than final product.
Context: A standard provider-shaped status page exposed checks, but not meaning, and did not suit different audiences equally well.
What I did: Defined a signal-to-surface architecture, normalised upstream monitor data, introduced intentional service roll-up logic, and split presentation into a calm public view and a more investigative operations view.
Why it mattered: Status can function as a trust surface rather than a branded wrapper around monitoring output.
What changed: Service condition became clearer, public communication became more deliberate, and operational visibility improved without forcing both audiences through the same interface.
Related writing: Owning the Status Surface · What owning the status surface looks like
Shaped ThreatScope Check as a calm, public-facing trust surface that translates scattered technical signals into a more legible view of digital exposure, posture and trust-related risk.
Context: Most public cyber tools either overwhelm with fragmented output or overstate certainty through simplistic scoring.
What I did: Defined the response model, evidence hierarchy, language, staged signal presentation and method boundaries so the surface communicates posture in a measured and usable way.
Why it mattered: The value was not in collecting signals. It was in turning them into a surface people could read without thinking like an operator or analyst.
What changed: The product moved toward an evidence-led public utility: more coherent, more legible and less dependent on alarm-driven security theatre.
Public artefact: ThreatScope Check
Work focused on collecting, shaping and interpreting technical signals over time without turning partial evidence into unsupported certainty.
Built a longitudinal observatory for the .au namespace to capture domain and DNS state over time, preserve evidence across a curated panel and support interpretation rather than one-off lookup behaviour.
Context: One-off checks are useful but shallow. The domain layer changes over time in ways a single lookup cannot see.
What I did: Shaped the collection model, cadence, storage pattern, analysis flow, reporting logic and public interpretation layer for a panel-based observational system.
Why it mattered: Repeated observation turns scattered public signals into a credible longitudinal record while preserving the distinction between observation and interpretation.
What changed: What was previously invisible or anecdotal became trackable, structured and publishable as a repeating public evidence surface.
Public artefact: .au Domain Observatory (.auDO) · Published reports
Built patterns for translating uneven technical inputs into a consistent internal evidence model suitable for interpretation, comparison and calmer public output.
Context: Raw inputs from different providers, checks and data sources rarely arrive in a form useful for direct presentation.
What I did: Defined internal shapes for signals, observation objects, service states and confidence cues so heterogeneous inputs could be interpreted deliberately and compared over time.
Why it mattered: Without normalisation, system outputs inherit provider assumptions and become harder to compare, govern or explain.
What changed: The architecture became more composable and the resulting surfaces more coherent.
Work focused on making decisions, accountability, risk and operating expectations explicit enough to support useful action.
Translated the ten-question argument from Domain Governance as a Trust Surface into a private baseline review and five bounded implementation guides.
Context: The essay established why domains should be treated as governance assets, but the argument still needed a practical adoption path that did not become another assessment platform, maturity model or reporting system.
What I did: Converted the ten starting questions into a private, browser-based baseline review. Then developed five practical guides and portable starter records covering domain inventory, registrar and DNS authority, email authority, incident readiness and recurring governance.
Why it mattered: A governance argument becomes more useful when people can identify what is unclear, understand what credible practice looks like and move the resulting action into systems and forums they already operate.
What changed: The work now provides a coherent path from argument, to baseline review, to bounded operating practice while retaining no accounts, scoring, retained organisational data or unsupported assurance claims.
Public artefacts: Domain Governance Baseline · Five practical guides · Source essay
Designed and embedded a technology governance framework in a complex, mission-critical organisation, strengthening stakeholder engagement and materially reducing incident escalations.
Context: Governance activity was reactive, escalation patterns were recurring, and stakeholder confidence in technology leadership was inconsistent.
What I did: Designed the framework structure, embedded operating cadences, clarified accountability lines and introduced deliberate patterns for escalation, communication and stakeholder reporting.
Why it mattered: Governance only works if it changes how decisions are made, how risk is surfaced and how accountability is exercised.
What changed: Incident escalations reduced by 30%. Stakeholder engagement became more consistent and less dependent on individual relationships.
Related writing: The governance gap in digital systems
Developed ways of expressing technology risk, control posture and delivery implications in language that can travel across operational, management and governance layers.
Context: Technology risks were either over-technical for decision-makers or over-simplified for meaningful governance.
What I did: Framed risk in plain language, linked operational realities to governance concerns and created communication patterns that preserved nuance without losing clarity.
Why it mattered: Good translation helps decision-makers act without pretending the complexity is not real.
What changed: Leadership could engage with technology risk as a governance matter rather than a technical one.
Related writing: Translating technology risk for boards
Structured a practical operating model for technology delivery and governance work, with clear cadences, issue structures, escalation paths, reporting views and team responsibilities.
Context: Delivery and governance activity was at risk of becoming fragmented, reactive and dependent on unwritten expectations.
What I did: Designed a working framework covering responsibilities, board and backlog structure, reporting rhythms, escalation logic and practical ways of working.
Why it mattered: Teams need an operating shape that reduces ambiguity and supports trust between delivery, governance and stakeholders.
What changed: Work became easier to classify, track, govern and communicate.
Work where delivery, governance, organisational change, budget discipline and leadership accountability had to hold together in real operating environments.
Led delivery of a major digital experience platform transformation for a large national organisation, on schedule and 10% under budget.
Context: The platform transformation affected public-facing services, content architecture and integration with internal systems.
What I did: Led planning, vendor management, delivery governance and implementation while maintaining schedule and budget discipline.
Why it mattered: Delivery in a mission-critical environment required governance discipline as much as project management.
What changed: The organisation moved to a modern platform while preserving service continuity and avoiding budget overrun.
Led a workplace platform modernisation programme to 95% staff adoption and developed the business case and enterprise strategy for responsible AI integration.
Context: The organisation required a major workplace uplift alongside a credible strategy for enterprise AI adoption.
What I did: Led the modernisation programme and developed the AI business case and adoption strategy across governance, risk, policy and rollout sequencing.
Why it mattered: Adoption at scale depends on deliberate change and a platform people can trust. AI adoption requires the same governance discipline.
What changed: The organisation achieved near-universal platform adoption and a governance-first path for AI integration.
Related writing: AI does not create a new domain of trust
Provided continuity of leadership across technology strategy, delivery governance and stakeholder engagement at executive level for a large national organisation.
Context: The organisation required continuity of technology leadership during a period of planned executive absence.
What I did: Maintained executive presence across leadership, board-level reporting, stakeholder engagement and operational decision-making for the technology function.
Why it mattered: Leadership continuity in a mission-critical environment is a governance matter, not simply a staffing one.
What changed: The organisation maintained strategic momentum, operational stability and stakeholder confidence through the transition.
Reworked a multi-service environment into a deliberate catalogue model, grouping services by meaning, priority and relationship rather than by platform sprawl or legacy naming.
Context: Multiple services and supporting systems had grown over time, making it harder to express what mattered and how the parts related.
What I did: Designed a clearer catalogue structure, grouped services into intentional families, reordered surfaces by importance and aligned presentation to operational value.
Why it mattered: Catalogue structure shapes perception. A poor grouping model creates noise; a strong one improves clarity and governance.
What changed: The environment became easier to read, manage and align to strategic narrative.
