Algorithmic Infrastructure and Platform Power: How Platforms Shape Access and Control

Last Updated June 18, 2026

Algorithmic infrastructure and platform power explain how computational systems become sites of control, dependency, access, visibility, coordination, and governance. Algorithms do not only classify, recommend, rank, route, optimize, retrieve, or automate. They often operate inside platforms that decide who can participate, what data is collected, which interfaces are available, how content is discovered, how services interconnect, how developers build, how users are measured, and how institutions depend on technical systems they do not fully control.

Platform power emerges when infrastructure becomes difficult to avoid. A platform may provide search, cloud computing, app distribution, social visibility, payment processing, logistics, identity, analytics, advertising, model access, data storage, API connectivity, or marketplace coordination. These services can create enormous value, but they also concentrate decision-making power in technical layers that shape opportunity, attention, cost, speech, competition, public knowledge, and institutional capacity.

Algorithmic infrastructure is therefore not just a technical foundation. It is also a governance environment. It establishes rules, defaults, incentives, metrics, permissions, rankings, standards, dependencies, and chokepoints. It can enable innovation and coordination, but it can also create lock-in, asymmetry, opacity, exclusion, surveillance, and unequal bargaining power.

This article introduces algorithmic infrastructure and platform power as core topics in algorithms and computational reasoning. It emphasizes that responsible computational analysis must examine not only how algorithms work, but also where they are embedded, who controls the surrounding infrastructure, who depends on it, and how power is exercised through technical systems.

This article explains algorithmic infrastructure, platform power, APIs, cloud dependencies, app stores, search systems, marketplaces, recommender systems, ranking infrastructure, data extraction, identity layers, payment rails, analytics platforms, model access, interface control, platform lock-in, gatekeeping, interoperability, observability, governance, and accountability. It emphasizes that platform power is not only exercised through visible policy. It is also exercised through defaults, rankings, permissions, metrics, architectures, access rules, and infrastructure dependencies.

Why Platform Power Matters

Platform power matters because many computational systems now depend on infrastructure owned, governed, priced, ranked, moderated, measured, or mediated by platforms. A publisher may depend on search visibility. A developer may depend on an app store or API. A business may depend on a marketplace, payment processor, cloud provider, analytics platform, or advertising system. A public institution may depend on cloud infrastructure, identity tools, data platforms, or model services.

These dependencies are not merely technical. They shape what organizations can build, what users can see, what data is collected, what costs are imposed, what rules apply, and what forms of accountability are possible.

Platform power should be analyzed as computational, economic, social, and institutional power at the same time.

Back to top ↑

What Algorithmic Infrastructure Means

Algorithmic infrastructure is the layered technical environment that enables algorithms to operate, scale, connect, and govern action. It includes cloud systems, APIs, databases, identity systems, ranking systems, recommender systems, analytics systems, advertising systems, payment systems, moderation systems, model-serving platforms, and data pipelines.

Infrastructure often becomes powerful because it is taken for granted. When a system becomes necessary, invisible, reliable enough, widely adopted, and difficult to replace, it becomes part of the operating environment for others.

Algorithmic infrastructure becomes powerful when others must build on top of it.

Back to top ↑

What Platform Power Means

Platform power is the ability of a platform to shape the behavior, options, visibility, costs, dependencies, rules, and outcomes of participants who rely on it. This power may be explicit, such as policy enforcement or account removal. It may also be infrastructural, such as changing an API, ranking function, default setting, data access policy, fee structure, or interoperability rule.

Platform power often works through asymmetry. The platform can observe many participants, change rules centrally, control interfaces, set metrics, govern access, and modify technical conditions. Participants often have less visibility into how decisions are made, fewer alternatives, and limited ability to negotiate.

Platform power is strongest when technical dependence, economic dependence, and informational asymmetry reinforce each other.

Back to top ↑

Infrastructure as a Control Layer

Infrastructure can exercise control without looking like control. A platform may not issue a direct command. It may change defaults, alter rankings, restrict API fields, modify fees, adjust moderation thresholds, redefine metrics, change data-retention rules, or redesign dashboards. Participants then adapt to the new environment.

This is why infrastructure should be analyzed as a control layer. It shapes the conditions under which other actors make decisions.

Infrastructure control is often exercised through technical conditions rather than direct instruction.

Back to top ↑

APIs, Interfaces, and Dependency

APIs are central to platform power because they define how other systems connect to a platform. APIs expose some capabilities, hide others, enforce authentication, apply rate limits, structure data formats, and define what kinds of applications can be built.

An API is a technical interface, but it is also a governance boundary. It determines what is possible, who is authorized, what data can be accessed, and how platform rules are enforced.

APIs are not merely developer conveniences. They are programmable boundaries of power.

Back to top ↑

Ranking, Visibility, and Attention

Ranking systems are one of the clearest forms of algorithmic platform power. Search results, feeds, recommendations, marketplace listings, app-store rankings, reviews, ads, and trending systems determine what receives attention.

Visibility is not evenly distributed. Ranking systems may reward relevance, engagement, freshness, popularity, payment, trust signals, compliance, platform goals, or predicted user behavior. These choices shape knowledge, commerce, culture, politics, and institutional reputation.

Ranking is not just ordering. It is structured visibility.

Back to top ↑

Data Extraction and Measurement

Platforms often gain power by measuring activity across many participants. They can observe users, sellers, developers, advertisers, creators, workers, customers, and organizations at scale. Measurement becomes infrastructure when platform metrics determine optimization, payment, ranking, moderation, recommendation, fraud scoring, and eligibility.

The power to measure is also the power to define what counts. Engagement, quality, trust, risk, relevance, productivity, conversion, satisfaction, safety, and compliance are not neutral categories. They are operationalized through data pipelines and models.

Measurement is never merely descriptive when it determines access, ranking, payment, and control.

Back to top ↑

Cloud Platforms and Operational Dependence

Cloud platforms provide compute, storage, networking, identity, monitoring, databases, queues, model endpoints, analytics, and deployment tools. This infrastructure allows organizations to build quickly and scale globally. It also creates operational dependence.

Cloud dependence can be technical, economic, organizational, and epistemic. A system may depend on proprietary managed services, provider-specific identity systems, billing models, monitoring tools, deployment workflows, and data formats. Exiting may require redesigning architecture, migrating data, retraining teams, rewriting code, and renegotiating governance.

Cloud platforms are not only infrastructure providers. They can become institutional dependencies.

Back to top ↑

Marketplaces, App Stores, and Gatekeeping

Marketplaces and app stores coordinate many participants through rules, rankings, fees, reviews, recommendations, distribution systems, fraud controls, and dispute mechanisms. They create access to users and customers, but also govern who may participate and under what conditions.

Gatekeeping can be necessary for safety, quality, security, fraud prevention, and user trust. But it can also concentrate decision-making power, create opacity, impose dependency, and favor platform interests.

Marketplaces and app stores are algorithmic institutions, not only software distribution channels.

Back to top ↑

Identity, Payments, and Access Rails

Identity and payment systems are especially powerful because they determine who can act and who can transact. Authentication, verification, fraud scoring, risk models, transaction monitoring, and compliance systems are forms of algorithmic infrastructure.

When identity or payment rails are platform-controlled, access to social participation, economic participation, publishing, development, and institutional operations may depend on technical rules and risk models that are difficult for participants to inspect.

Identity and payment systems turn infrastructure into participation control.

Back to top ↑

Model Platforms and AI Infrastructure

AI systems increasingly depend on model platforms, data platforms, retrieval systems, vector databases, evaluation tools, model marketplaces, cloud GPUs, safety filters, content policies, prompt-management tools, and observability systems. This creates a new layer of platform power around model access and computational knowledge production.

Model platforms may shape which capabilities are available, which use cases are allowed, what data may be processed, what outputs are filtered, what costs apply, what logs are retained, what APIs exist, and how downstream systems are evaluated.

AI platform power is not only about models. It is about the infrastructure around models.

Back to top ↑

Interoperability, Portability, and Lock-In

Interoperability allows systems to communicate. Portability allows data, applications, workflows, models, or users to move between systems. Lock-in occurs when exit becomes costly, impractical, risky, or strategically discouraged.

Lock-in may be technical, such as proprietary APIs or data formats. It may be economic, such as data egress fees or marketplace dependence. It may be social, such as user networks that cannot move. It may be organizational, such as teams trained around one platform’s tools.

Exit is not a last-minute feature. It is a design property.

Back to top ↑

Observability, Audit, and Platform Accountability

Platform accountability depends on evidence. Participants need to understand access decisions, ranking changes, API behavior, billing changes, moderation actions, fraud flags, model outputs, data-retention practices, and dependency failures.

But platform systems often operate through internal models, proprietary metrics, complex policies, and large-scale automation. This makes observability and audit difficult. A responsible platform should preserve enough evidence for affected parties, regulators, researchers, developers, and internal governance teams to understand consequential decisions.

Accountability requires infrastructure that can explain infrastructure.

Back to top ↑

Governance and Institutional Responsibility

Platform power creates institutional responsibility because platforms shape the conditions under which others act. The more central a platform becomes, the greater its influence over markets, knowledge, speech, work, infrastructure, and public institutions.

Governance questions include transparency, due process, appeal, interoperability, data rights, competition, security, privacy, public-interest obligations, algorithmic accountability, risk assessment, and independent oversight.

Platform governance should match the scale of platform dependency and consequence.

Back to top ↑

Representation Risk

Representation risk appears when platforms describe infrastructure decisions as neutral, automatic, objective, or purely technical. A ranking may be described as relevance while also reflecting business incentives, engagement goals, data availability, policy constraints, or strategic priorities. A suspension may be described as safety enforcement while depending on opaque risk models. A cloud outage may be described as isolated while affecting many dependent institutions. An API change may be described as modernization while disrupting entire ecosystems.

Responsible analysis asks how platform systems represent their own power.

Back to top ↑

Back to top ↑

Mathematics, Computation, and Modeling

A simple platform-dependency score can be represented as:

A visibility share can be represented as:

A switching-cost estimate can be represented as:

An API dependency ratio can be written as:

A platform risk index can be represented as:

These formulas simplify complex institutional systems, but they provide a way to reason about dependency, visibility, switching cost, API reliance, and governance risk.

Back to top ↑

Python Workflow: Platform Power Audit

The Python workflow below creates a dependency-light audit for algorithmic infrastructure and platform power. It scores access dependence, visibility dependence, API dependence, data dependence, cost dependence, switching difficulty, interoperability, transparency, auditability, appeal mechanisms, governance review, and communication clarity.

# platform_power_audit.py
# Dependency-light workflow for auditing algorithmic infrastructure and platform power.

from __future__ import annotations

from dataclasses import asdict, dataclass
from pathlib import Path
import csv
import json
from statistics import mean

ARTICLE_ROOT = Path(__file__).resolve().parents[1]
TABLES = ARTICLE_ROOT / "outputs" / "tables"
JSON_DIR = ARTICLE_ROOT / "outputs" / "json"


@dataclass(frozen=True)
class PlatformPowerCase:
    case_name: str
    platform_context: str
    dependency_goal: str
    access_dependence: float
    visibility_dependence: float
    api_dependence: float
    data_dependence: float
    cost_dependence: float
    switching_difficulty: float
    interoperability: float
    transparency: float
    auditability: float
    appeal_mechanism: float
    governance_review: float
    communication_clarity: float


def clamp(value: float, low: float = 0.0, high: float = 100.0) -> float:
    return max(low, min(high, value))


def platform_power_risk(case: PlatformPowerCase) -> float:
    return clamp(
        100.0 * (
            0.11 * case.access_dependence
            + 0.11 * case.visibility_dependence
            + 0.10 * case.api_dependence
            + 0.10 * case.data_dependence
            + 0.09 * case.cost_dependence
            + 0.11 * case.switching_difficulty
            + 0.10 * (1.0 - case.interoperability)
            + 0.09 * (1.0 - case.transparency)
            + 0.08 * (1.0 - case.auditability)
            + 0.06 * (1.0 - case.appeal_mechanism)
            + 0.04 * (1.0 - case.governance_review)
            + 0.01 * (1.0 - case.communication_clarity)
        )
    )


def platform_accountability_score(case: PlatformPowerCase) -> float:
    return clamp(
        100.0 * (
            0.18 * case.interoperability
            + 0.18 * case.transparency
            + 0.17 * case.auditability
            + 0.14 * case.appeal_mechanism
            + 0.17 * case.governance_review
            + 0.16 * case.communication_clarity
        )
    )


def diagnose(risk: float, accountability: float) -> str:
    if risk >= 70 and accountability <= 45:
        return "high platform power risk with weak accountability"
    if risk >= 55:
        return "substantial platform dependency; strengthen portability, transparency, audit, appeals, and governance"
    if accountability >= 75:
        return "stronger accountability posture, but dependency should still be monitored"
    return "moderate platform risk; improve evidence, interoperability, and participant communication"


def dependency_score(access: float, visibility: float, cost: float, switching: float, evidence: float) -> float:
    return round(100.0 * (0.22 * access + 0.22 * visibility + 0.18 * cost + 0.24 * switching + 0.14 * evidence), 3)


def switching_cost(migration: float, rebuild: float, training: float, downtime: float, lost_network: float) -> float:
    return round(migration + rebuild + training + downtime + lost_network, 3)


def api_dependency_ratio(platform_requests: float, total_requests: float) -> float:
    return round(platform_requests / total_requests, 6) if total_requests else 0.0


def visibility_share(actor_exposure: float, total_exposure: float) -> float:
    return round(actor_exposure / total_exposure, 6) if total_exposure else 0.0


def build_cases() -> list[PlatformPowerCase]:
    return [
        PlatformPowerCase(
            case_name="Search-dependent publisher",
            platform_context="Publisher depends on search indexing, ranking, snippets, crawl behavior, and traffic distribution.",
            dependency_goal="preserve discoverability while reducing single-channel visibility dependence",
            access_dependence=0.78,
            visibility_dependence=0.92,
            api_dependence=0.34,
            data_dependence=0.64,
            cost_dependence=0.52,
            switching_difficulty=0.74,
            interoperability=0.46,
            transparency=0.38,
            auditability=0.42,
            appeal_mechanism=0.34,
            governance_review=0.56,
            communication_clarity=0.58,
        ),
        PlatformPowerCase(
            case_name="Cloud-native data platform",
            platform_context="Institution depends on managed databases, object storage, queues, identity, monitoring, and deployment tooling.",
            dependency_goal="maintain operational capacity while preserving exit options and internal evidence",
            access_dependence=0.72,
            visibility_dependence=0.22,
            api_dependence=0.84,
            data_dependence=0.86,
            cost_dependence=0.78,
            switching_difficulty=0.88,
            interoperability=0.44,
            transparency=0.62,
            auditability=0.72,
            appeal_mechanism=0.46,
            governance_review=0.68,
            communication_clarity=0.64,
        ),
        PlatformPowerCase(
            case_name="Marketplace seller ecosystem",
            platform_context="Sellers depend on marketplace ranking, review systems, fees, fulfillment metrics, and dispute mechanisms.",
            dependency_goal="evaluate ranking, fee, access, and appeal dependence",
            access_dependence=0.86,
            visibility_dependence=0.88,
            api_dependence=0.62,
            data_dependence=0.72,
            cost_dependence=0.82,
            switching_difficulty=0.80,
            interoperability=0.36,
            transparency=0.34,
            auditability=0.40,
            appeal_mechanism=0.38,
            governance_review=0.48,
            communication_clarity=0.52,
        ),
        PlatformPowerCase(
            case_name="AI model API dependency",
            platform_context="Product depends on model API behavior, rate limits, safety policies, cost changes, logging, and version updates.",
            dependency_goal="preserve model capability while supporting fallback, evaluation, and governance",
            access_dependence=0.82,
            visibility_dependence=0.30,
            api_dependence=0.90,
            data_dependence=0.70,
            cost_dependence=0.78,
            switching_difficulty=0.76,
            interoperability=0.50,
            transparency=0.48,
            auditability=0.62,
            appeal_mechanism=0.40,
            governance_review=0.66,
            communication_clarity=0.60,
        ),
    ]


def calculator_examples() -> list[dict[str, object]]:
    return [
        {
            "example": "platform_dependency_score",
            "access_dependence": 0.80,
            "visibility_dependence": 0.90,
            "cost_dependence": 0.70,
            "switching_difficulty": 0.85,
            "evidence_dependence": 0.65,
            "dependency_score": dependency_score(0.80, 0.90, 0.70, 0.85, 0.65),
        },
        {
            "example": "switching_cost",
            "migration": 45000,
            "rebuild": 120000,
            "training": 18000,
            "downtime": 24000,
            "lost_network": 75000,
            "switching_cost": switching_cost(45000, 120000, 18000, 24000, 75000),
        },
        {
            "example": "api_dependency_ratio",
            "platform_requests": 850000,
            "total_requests": 1000000,
            "api_dependency_ratio": api_dependency_ratio(850000, 1000000),
        },
        {
            "example": "visibility_share",
            "actor_exposure": 250000,
            "total_exposure": 5000000,
            "visibility_share": visibility_share(250000, 5000000),
        },
    ]


def run_audit() -> list[dict[str, object]]:
    rows: list[dict[str, object]] = []

    for case in build_cases():
        risk = platform_power_risk(case)
        accountability = platform_accountability_score(case)
        rows.append({
            **asdict(case),
            "platform_power_risk": round(risk, 3),
            "platform_accountability_score": round(accountability, 3),
            "diagnostic": diagnose(risk, accountability),
        })

    return rows


def write_csv(path: Path, rows: list[dict[str, object]]) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)

    with path.open("w", newline="", encoding="utf-8") as handle:
        writer = csv.DictWriter(handle, fieldnames=list(rows[0].keys()))
        writer.writeheader()
        writer.writerows(rows)


def write_json(path: Path, payload: object) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    path.write_text(json.dumps(payload, indent=2, sort_keys=True), encoding="utf-8")


def summarize(rows: list[dict[str, object]]) -> dict[str, object]:
    return {
        "case_count": len(rows),
        "average_platform_power_risk": round(mean(float(row["platform_power_risk"]) for row in rows), 3),
        "average_platform_accountability_score": round(mean(float(row["platform_accountability_score"]) for row in rows), 3),
        "highest_risk_case": max(rows, key=lambda row: float(row["platform_power_risk"]))["case_name"],
        "highest_accountability_case": max(rows, key=lambda row: float(row["platform_accountability_score"]))["case_name"],
        "interpretation": "Platform power risk increases with access dependence, visibility dependence, API dependence, data dependence, cost dependence, switching difficulty, low interoperability, low transparency, weak auditability, weak appeal mechanisms, and weak governance review."
    }


def main() -> None:
    audit_rows = run_audit()
    summary = summarize(audit_rows)
    calculator_rows = calculator_examples()

    write_csv(TABLES / "platform_power_audit.csv", audit_rows)
    write_csv(TABLES / "platform_power_audit_summary.csv", [summary])
    write_csv(TABLES / "platform_power_calculator_examples.csv", calculator_rows)

    write_json(JSON_DIR / "platform_power_audit.json", audit_rows)
    write_json(JSON_DIR / "platform_power_audit_summary.json", summary)
    write_json(JSON_DIR / "platform_power_calculator_examples.json", calculator_rows)

    print("Algorithmic infrastructure and platform power audit complete.")
    print(TABLES / "platform_power_audit.csv")


if __name__ == "__main__":
    main()

This workflow treats platform power as an auditable dependency structure rather than a vague institutional concern.

Back to top ↑

R Workflow: Platform Dependency Summary

The R workflow reads the Python-generated audit table and creates summary outputs and visualizations using base R. It compares platform power risk and accountability across synthetic platform-dependency cases.

# platform_power_summary.R
# Base R workflow for summarizing algorithmic infrastructure and platform power audits.

args <- commandArgs(trailingOnly = FALSE)
file_arg <- grep("^--file=", args, value = TRUE)

if (length(file_arg) > 0) {
  script_path <- normalizePath(sub("^--file=", "", file_arg[1]), mustWork = TRUE)
  article_root <- normalizePath(file.path(dirname(script_path), ".."), mustWork = TRUE)
} else {
  article_root <- getwd()
}

setwd(article_root)

tables_dir <- file.path(article_root, "outputs", "tables")
figures_dir <- file.path(article_root, "outputs", "figures")

if (!dir.exists(tables_dir)) {
  dir.create(tables_dir, recursive = TRUE)
}

if (!dir.exists(figures_dir)) {
  dir.create(figures_dir, recursive = TRUE)
}

audit_path <- file.path(tables_dir, "platform_power_audit.csv")

if (!file.exists(audit_path)) {
  stop(paste("Missing", audit_path, "Run the Python workflow first."))
}

data <- read.csv(audit_path, stringsAsFactors = FALSE)

summary_table <- data.frame(
  case_count = nrow(data),
  average_platform_power_risk = mean(data$platform_power_risk),
  average_platform_accountability_score = mean(data$platform_accountability_score),
  highest_risk_case = data$case_name[which.max(data$platform_power_risk)],
  highest_accountability_case = data$case_name[which.max(data$platform_accountability_score)]
)

write.csv(
  summary_table,
  file.path(tables_dir, "r_platform_power_summary.csv"),
  row.names = FALSE
)

comparison_matrix <- rbind(
  data$platform_power_risk,
  data$platform_accountability_score
)

colnames(comparison_matrix) <- data$case_name
rownames(comparison_matrix) <- c(
  "Platform power risk",
  "Platform accountability score"
)

png(
  file.path(figures_dir, "platform_power_risk_vs_accountability.png"),
  width = 1500,
  height = 850
)

barplot(
  comparison_matrix,
  beside = TRUE,
  las = 2,
  ylim = c(0, 100),
  ylab = "Score",
  main = "Platform Power Risk vs. Accountability"
)

legend(
  "topleft",
  legend = rownames(comparison_matrix),
  pch = 15,
  bty = "n"
)

grid()
dev.off()

calculator_path <- file.path(tables_dir, "platform_power_calculator_examples.csv")

if (file.exists(calculator_path)) {
  calculators <- read.csv(calculator_path, stringsAsFactors = FALSE)
  write.csv(
    calculators,
    file.path(tables_dir, "r_platform_power_calculator_examples.csv"),
    row.names = FALSE
  )
}

print(summary_table)

This workflow helps compare dependency, access risk, visibility risk, lock-in, interoperability, transparency, auditability, appeals, and governance readiness.

Back to top ↑

GitHub Repository

The companion repository for this article provides reproducible code, synthetic datasets, workflow documentation, generated outputs, platform-dependency calculators, switching-cost examples, API-dependency examples, visibility-share examples, governance checklists, and Canvas-ready artifacts that extend the article into executable examples.

Back to top ↑

A Practical Method for Evaluating Platform Power

A practical method for evaluating platform power begins by mapping dependency. What platform services are required? Which systems, workflows, revenues, users, data flows, or public functions depend on them? What happens if access changes, rankings shift, fees increase, APIs break, data export fails, or a platform rule changes?

Platform-power analysis is strongest when it connects technical architecture to dependency, institutional consequence, and accountable governance.

Back to top ↑

Common Pitfalls

A common pitfall is treating platform systems as neutral tools. Platforms can be useful, efficient, innovative, and enabling while still concentrating power. The question is not whether platforms are good or bad in general. The question is how power is structured, exercised, measured, constrained, reviewed, and made accountable.

Common pitfalls include:

• treating infrastructure as invisible: dependency disappears from analysis;
• confusing access with fairness: participation may be allowed but visibility may be uneven;
• ignoring API governance: interface changes can reshape entire ecosystems;
• treating ranking as neutral relevance: ranking reflects objectives, data, metrics, and incentives;
• overlooking switching costs: exit may be impractical even when technically possible;
• trusting platform metrics without review: measurement systems define what counts;
• missing appeal and remediation gaps: automated decisions can be hard to challenge;
• assuming cloud convenience eliminates dependence: managed services can create operational lock-in;
• ignoring public-interest effects: platform decisions may affect knowledge, markets, speech, and institutions;
• using platform language uncritically: self-descriptions may obscure asymmetry and governance gaps.

The remedy is infrastructural literacy: dependency maps, interface review, visibility analysis, portability planning, audit evidence, appeal mechanisms, and governance proportional to platform power.

Back to top ↑

Why Platform Power Shapes Computational Judgment

Algorithmic infrastructure and platform power shape computational judgment because algorithms operate within systems of dependency. A ranking model is not only a mathematical procedure. It is part of a visibility system. An API is not only an interface. It is a boundary of permission. A cloud service is not only a resource. It is an operational dependency. A marketplace is not only a transaction environment. It is a governed economic system. A model platform is not only an AI capability. It is a control point for downstream automation.

Responsible computational reasoning must therefore ask more than “how does the algorithm work?” It must also ask: who controls the infrastructure? who depends on it? what can be changed unilaterally? who sees the evidence? what are the costs of exit? what metrics define success? what appeal paths exist? what public consequences follow?

Platform power is not separate from algorithmic reasoning. It is one of the conditions under which algorithmic systems become consequential.

The next article turns to online algorithms and decisions under arrival, where platforms often make decisions under continuous streams of users, content, bids, signals, requests, and changing conditions.

Back to top ↑

Related Articles

• Edge Computing and Embedded Algorithms
• Cloud Computing and Algorithmic Infrastructure
• Software Architecture as Algorithmic Infrastructure
• Ranking Signals and Relevance Models
• Information Retrieval and Search Architecture
• Knowledge Graphs and Semantic Retrieval
• Data Pipelines and Algorithmic Workflow Design

Further Reading

• Bowker, G.C. and Star, S.L. (1999) Sorting Things Out: Classification and Its Consequences. Cambridge, MA: MIT Press.
• Crawford, K. (2021) Atlas of AI: Power, Politics, and the Planetary Costs of Artificial Intelligence. New Haven, CT: Yale University Press.
• Gillespie, T. (2010) ‘The politics of “platforms”’, New Media & Society, 12(3), pp. 347–364.
• Helmond, A. (2015) ‘The platformization of the web: Making web data platform ready’, Social Media + Society, 1(2).
• Noble, S.U. (2018) Algorithms of Oppression: How Search Engines Reinforce Racism. New York: New York University Press.
• Pasquale, F. (2015) The Black Box Society: The Secret Algorithms That Control Money and Information. Cambridge, MA: Harvard University Press.
• Plantin, J.-C., Lagoze, C., Edwards, P.N. and Sandvig, C. (2018) ‘Infrastructure studies meet platform studies in the age of Google and Facebook’, New Media & Society, 20(1), pp. 293–310.
• Srnicek, N. (2017) Platform Capitalism. Cambridge: Polity Press.
• Star, S.L. and Ruhleder, K. (1996) ‘Steps toward an ecology of infrastructure: Design and access for large information spaces’, Information Systems Research, 7(1), pp. 111–134.
• van Dijck, J., Poell, T. and de Waal, M. (2018) The Platform Society: Public Values in a Connective World. Oxford: Oxford University Press.

References

• Bowker, G.C. and Star, S.L. (1999) Sorting Things Out: Classification and Its Consequences. Cambridge, MA: MIT Press.
• Crawford, K. (2021) Atlas of AI: Power, Politics, and the Planetary Costs of Artificial Intelligence. New Haven, CT: Yale University Press.
• Gillespie, T. (2010) ‘The politics of “platforms”’, New Media & Society, 12(3), pp. 347–364.
• Gillespie, T. (2018) Custodians of the Internet: Platforms, Content Moderation, and the Hidden Decisions That Shape Social Media. New Haven, CT: Yale University Press.
• Helmond, A. (2015) ‘The platformization of the web: Making web data platform ready’, Social Media + Society, 1(2).
• Noble, S.U. (2018) Algorithms of Oppression: How Search Engines Reinforce Racism. New York: New York University Press.
• Pasquale, F. (2015) The Black Box Society: The Secret Algorithms That Control Money and Information. Cambridge, MA: Harvard University Press.
• Plantin, J.-C., Lagoze, C., Edwards, P.N. and Sandvig, C. (2018) ‘Infrastructure studies meet platform studies in the age of Google and Facebook’, New Media & Society, 20(1), pp. 293–310.
• Srnicek, N. (2017) Platform Capitalism. Cambridge: Polity Press.
• Star, S.L. and Ruhleder, K. (1996) ‘Steps toward an ecology of infrastructure: Design and access for large information spaces’, Information Systems Research, 7(1), pp. 111–134.
• van Dijck, J., Poell, T. and de Waal, M. (2018) The Platform Society: Public Values in a Connective World. Oxford: Oxford University Press.
• Zuboff, S. (2019) The Age of Surveillance Capitalism. New York: PublicAffairs.

Back to top ↑