[Paper] From Symbol to Meaning: Ontological and Philosophical Reflections on Large Language Models in Information Systems Engineering
Source: arXiv - 2603.17659v1
Overview
The paper From Symbol to Meaning examines how the rise of large language models (LLMs) forces a rethink of the philosophical underpinnings of Information Systems Engineering (ISE). By weaving together ideas from semiotics, ontology, and contemporary AI, the author argues that LLMs are not just powerful code‑generation tools—they act as “epistemic agents” that reshape how we model, represent, and reason about data and systems.
Key Contributions
- Philosophical Re‑framing: Connects classic philosophical traditions (Peirce’s semiotics, Heidegger’s ontology, Floridi’s philosophy of information) to the mechanics of modern LLMs.
- Ontological Shift: Shows how generative models blur the line between symbol (raw token) and meaning (contextual interpretation), challenging static data models used in traditional IS design.
- Epistemic Agency Concept: Proposes viewing LLMs as agents that co‑produce knowledge rather than passive executors of pre‑defined logic.
- Ethical Blueprint: Outlines a set of transparency and human‑centred criteria that should guide the integration of LLMs into enterprise information systems.
- Design Implications: Provides a high‑level roadmap for embedding LLM‑driven components while preserving traceability, accountability, and interpretability.
Methodology
The author adopts a conceptual‑analytic approach:
- Literature Synthesis: Reviews key works in semiotics, ontology, and information ethics to build a philosophical scaffold.
- Technical Mapping: Breaks down the internal workflow of LLMs (tokenization → embedding → transformer‑based attention → next‑token prediction) and aligns each step with philosophical notions of sign, referent, and meaning.
- Critical Reflection: Uses thought experiments and case snippets (e.g., LLM‑generated API specs, automated requirements extraction) to illustrate where traditional IS models succeed or break down.
- Normative Framework Construction: Derives a set of design principles that balance model autonomy with human oversight, grounded in the earlier philosophical analysis.
The methodology stays high‑level—no new empirical experiments are reported—making the argument accessible to developers who are familiar with how LLMs work but not with deep philosophical jargon.
Results & Findings
| Finding | What It Means for IS Engineering |
|---|---|
| LLMs collapse the symbol/meaning hierarchy | Data schemas can no longer be treated as immutable “truths”; they become fluid interpretations that evolve with model updates. |
| Model outputs act as provisional knowledge claims | System designers must treat LLM suggestions as hypotheses that need validation, not final specifications. |
| Transparency gaps are epistemic risks | Without explicit provenance (prompt, temperature, fine‑tuning data), downstream systems inherit hidden biases. |
| Human‑in‑the‑loop remains essential | Even with high‑performing LLMs, domain experts must mediate between generated artefacts and regulatory/compliance constraints. |
These insights collectively suggest that the traditional “design‑then‑implement” pipeline must be augmented with continuous validation loops and meta‑data tracking.
Practical Implications
- Design‑by‑Prompt: Engineers can prototype data models, API contracts, or UI text by prompting LLMs, but must embed versioned prompts and response logs into the CI/CD pipeline for auditability.
- Dynamic Schema Management: Adopt schema‑as‑code tools (e.g., Liquibase, dbt) that support runtime schema evolution driven by LLM‑generated migrations, coupled with automated regression tests.
- Explainability Layer: Wrap LLM calls with a “reasoning wrapper” that captures attention weights, token probabilities, and source data snippets, exposing them to developers and auditors.
- Ethical Guardrails: Implement policy‑based filters (e.g., OpenAI’s content moderation) and human review checkpoints before LLM outputs affect production systems.
- Knowledge‑Centric Architecture: Shift from purely data‑centric pipelines to knowledge‑centric ones where LLMs contribute to the inference layer, and the system records the provenance of each inference.
In short, the paper nudges the industry toward transparent, accountable, and co‑creative AI‑augmented system engineering practices.
Limitations & Future Work
- Conceptual Scope: The paper stays at a philosophical and architectural level; it does not provide concrete performance benchmarks or tooling prototypes.
- Domain Specificity: While the arguments are framed for general IS engineering, concrete guidelines for highly regulated sectors (e.g., finance, healthcare) are left for later work.
- Empirical Validation: Future research could involve case studies where the proposed design principles are applied to real‑world LLM‑powered systems, measuring impacts on maintainability, compliance, and developer productivity.
For developers eager to experiment, a practical first step is to start logging every LLM interaction (prompt, parameters, response) as part of your version control system. This simple habit aligns with the paper’s call for traceability and sets the stage for the more sophisticated knowledge‑centric pipelines the author envisions.
Authors
- José Palazzo Moreira de Oliveira
Paper Information
- arXiv ID: 2603.17659v1
- Categories: cs.SE
- Published: March 18, 2026
- PDF: Download PDF