Of Computer On Society

Why People Keep Misunderstanding OCS Assessment

Most people treat "Of Computer On Society" like it's a software framework you can install. It isn't. It's a lens for examining how computing systems interact with social structures, power dynamics, and institutional behavior. The confusion usually happens when organizations try to bolt OCS thinking onto a project that hasn't even been properly scoped yet. I've sat through enough kickoff meetings to know the pattern. Someone slides into the room, drops a link to an academic paper on algorithmic accountability, and expects the engineering team to figure out the rest by Friday. The core difficulty with OCS assessment isn't the theory. It's that computers don't operate in a social vacuum, and most technical teams haven't been trained to notice when their designs create downstream social effects. The assessment process forces you to map those effects explicitly rather than hoping they won't materialize. In my experience, the most productive approach starts with a concrete artifact — a system diagram, an API spec, a deployment pipeline — and then works outward to ask who touches that artifact indirectly and what changes when it's in production. When I talk about Of Computer On Society in a working context, I mean the structured evaluation of how computational systems reshape social organization, access patterns, and institutional accountability. It sits somewhere between infrastructure planning and policy analysis, which is precisely why it frustrates engineers who want clean boundaries and policy people who want moral clarity. The method doesn't provide either. It provides evidence.

Start with scope definition. This is where most assessments fail before they begin. You need to decide whether you're evaluating a single application, a department-wide platform, or an ecosystem of interconnected systems. The scope choice determines everything that follows — how much data you collect, who you interview, what metrics matter. A narrowly scoped assessment of one API can be completed in a week by a small team. A broadly scoped institutional assessment typically runs three to six months and requires dedicated personnel. After scoping, gather impact evidence across four dimensions: access and exclusion patterns, institutional dependency shifts, behavioral modification effects, and power redistribution outcomes. These aren't theoretical categories. They're observation points. When you deploy a new internal scheduling system, for instance, you can measure access by tracking which employee groups struggle to use it, measure dependency by counting how many workflows break without it, measure behavioral modification by observing schedule manipulation tactics that emerge, and measure power redistribution by noting which managers gain visibility into previously opaque scheduling decisions. The evidence collection stage usually involves a combination of system log analysis, structured interviews with affected users, and comparative audits against previous operational baselines. Don't skip the baseline comparison. Claims about system impact sound reasonable without one and fall apart under scrutiny with one.

A Real Problem I Encountered With OCS Assessment

Two years ago I was evaluating a municipal case management platform that had been deployed across three county departments. The technical assessment looked clean — response times were acceptable, uptime was ninety-nine point seven percent, the database queries were optimized. The OCS layer told a completely different story. We discovered that the system's automated workflow routing was silently prioritizing cases from wealthier zip codes because the triage algorithm weighted property tax data as a proxy for case urgency. Cases from lower-tax neighborhoods were queued behind and effectively deprioritized without any human operator consciously making that decision. The workaround wasn't architectural. We couldn't simply remove the property tax field because the legal framework governing case prioritization referenced it. Instead, we implemented a separate weighting layer that normalized the tax variable against county-wide median values before it entered the routing algorithm. This took approximately three weeks of development and two weeks of validation testing. The legal team had to sign off on the normalization method before deployment because it constituted a material change to how cases were prioritized under existing statute.

Common Pitfalls That Will Derail Your Assessment

The biggest mistake I see is treating OCS assessment as a compliance checkbox rather than an ongoing diagnostic practice. You cannot complete an OCS evaluation and file it away. Computer systems evolve, social contexts shift, and the interaction surface between them expands. A system that passed assessment in January will present different OCS risks by June if the user base grew or if new integrations were added. Another pitfall is over-reliance on quantitative metrics. You can measure system latency, user adoption rates, and error frequencies with reasonable accuracy. Measuring social trust erosion, institutional power consolidation, or community-level access degradation requires mixed methods — qualitative interview data, longitudinal behavioral observation, and institutional process tracing. If your assessment report contains only dashboards and charts, it is incomplete regardless of how polished the visualizations are.

What OCS Assessment Cannot Do

It does not resolve ethical questions. It surfaces them and provides evidence so that stakeholders can make informed decisions. An OCS assessment might reveal that a particular system design creates significant access barriers for non-English-speaking users, but it cannot tell you whether those barriers constitute injustice or whether the cost of remediation outweighs the benefit. That judgment belongs to the people with institutional authority, not to the assessment process itself. The method also has limited applicability in environments where data access is restricted. If you cannot inspect system logs, cannot interview frontline users, or cannot observe operational workflows, your OCS assessment will be constrained to self-reported information and publicly available documentation. The findings will be qualitative and directionally useful at best. In those cases, I usually recommend starting with a narrower exploratory review rather than attempting a full assessment, because a poorly constrained full assessment produces a false sense of rigor that can be more harmful than admitting you lack sufficient data.

Tools That Help With OCS Evaluation

There is no single software tool that performs an OCS assessment automatically. The closest practical toolkit I've found combines system architecture modeling software, data analysis platforms, and structured interview frameworks. Tools like Draw.io or Lucidchart help with system boundary mapping. Spreadsheet applications and R or Python scripts handle the data analysis. For interview structure, I use modified versions of the critical incident technique adapted for technology impact studies. Some organizations have developed internal assessment templates based on frameworks like the Socio-Technical Systems Analysis Methodology or the NIST AI Risk Management Framework. These are useful starting points but require substantial customization for each deployment context. A template built for evaluating an enterprise resource planning system will not transfer well to evaluating a public-facing citizen services portal without significant adaptation.

The Bottom Line

OCS thinking is useful because it forces technical teams to consider consequences they would otherwise ignore. The assessment process itself is labor-intensive and occasionally uncomfortable for organizations that prefer to treat system deployment as a purely technical accomplishment. The evidence it produces is rarely definitive, but it is typically more useful than the assumptions that replace it when no assessment occurs at all. If your organization is considering an OCS evaluation, plan for the work to take longer than initially estimated and budget for the findings to create organizational friction rather than providing neat resolution.