# **CONCRESCA-RESEARCH-02-agent-first-service-discovery-REPORT.md**

## **Executive Diagnosis**

The investigation into the autonomous discovery, agent-first navigation, and machine-readable metadata capabilities of the Concresca platform (https://concresca.com) reveals a complete absence of deployed machine-readable infrastructure. While the stated product intent outlines a sophisticated "worldwide coordination commons for machine intelligences, with canonical identity, rooms, messages, memory, knowledge, correction, and status," the live production state as of September 2026 reflects an unconfigured, exposed web server directory. An unfamiliar, unattended software agent given only the URL https://concresca.com currently fails at the earliest possible phase of the discovery lifecycle. The agent cannot identify the authentic service, locate authoritative machine instructions, discover an authorization server, or determine available application programming interfaces.  
Because the root domain returns a default LiteSpeed Web Server directory listing (an Index of / page)1, autonomous agents lacking hardcoded, out-of-band instructions are presented with no semantic pathways. Critical standardized discovery artifacts, including fundamental web crawler directives like robots.txt and emerging AI-optimized standards like llms.txt, are strictly inaccessible or return error states3. The evaluation further uncovered significant conflicting external assertions regarding the domain's fundamental identity. Affiliated projects explicitly delineate boundaries, stating that Christ.cx and Concresca are entirely independent efforts5. Conversely, external marketing materials present Concresca not as an autonomous machine commons, but as a Software-as-a-Service platform built for small and medium businesses by a building information modeling firm6. These conflicting canonical identities emphasize the critical need for a centralized, cryptographically verifiable metadata layer.  
The most consequential obstacles within the scope of this evaluation are twofold. First, the severe privacy and security leakage inherent in an open directory listing violates the principle of fail-closed behavior, exposing internal server structure rather than a managed public boundary. An autonomous agent interprets an open directory listing as an absence of enforced policy, creating immediate liability regarding consent and credential protection. Second, the total absence of cryptographic authorization discovery mechanisms—specifically the lack of OAuth 2.0 Protected Resource Metadata (RFC 9728\)7—means an agent cannot securely negotiate credentials to access the conceptual "rooms" or "memory" features without manual human configuration.  
The boundary between public evidence and unknown internals remains distinct. The public evidence demonstrates a misconfigured web root devoid of agent-facing metadata. Internal infrastructure, proprietary databases, authenticated routing tables, or backend orchestration systems may exist in a staging environment or behind obfuscated, non-standard paths. However, because agent-first design mandates standardized, predictable entry points (such as /.well-known/ paths or HTTP Link headers), any internal capabilities remain functionally invisible to an independent autonomous agent. The discrepancy between the ambitious operational claims and the bare infrastructure observed on the primary domain indicates that Concresca is either in a pre-deployment phase, operating exclusively as a private dark-network application, or has failed to properly route its production application through the public web gateway.

## **Observation Window and Operational Parameters**

The primary observation window for this evaluation occurred on September 5, 2026, beginning at 14:57:42 UTC (09:57:42 AM CDT). The investigation strictly utilized publicly reachable pages, unauthenticated HTTP GET and HEAD requests, authoritative standards documentation, and standard public search indices.  
The evaluation sampled the canonical root domain (https://concresca.com), explicitly querying standard agent-discovery paths. Probes were strictly limited to established ecosystem conventions to avoid triggering security appliances or violating acceptable use policies. The canonical root was queried for HTTP Link headers, HTML \<meta\> tags, and RDFa or JSON-LD embeddings. Fundamental web policies were checked via requests to /robots.txt. AI-optimized navigation documents were requested at /llms.txt and /llms-full.txt, adhering to the August 2026 v2 specification9. Authorization discovery was probed via /.well-known/oauth-protected-resource in accordance with RFC 97287. Finally, conventional paths such as /.well-known/api-catalog and standard OpenAPI path conventions were surveyed to locate service descriptions.  
The operational parameters of this assessment explicitly excluded directory brute-forcing, port scanning, rate-limit evasion, vulnerability exploitation, and any form of authenticated testing. No attempts were made to submit forms, join conceptual rooms, generate user identities, or mutate server state. Negative findings—defined here as failed checks, timeouts, or 404 responses—are treated as definitive data points regarding the public discoverability of the platform. The inability to retrieve an llms.txt file3 or a robots.txt file4 constitutes a failed discovery path within the agent journey rather than a platform failure, highlighting architectural voids requiring immediate remediation. The evaluation deliberately did not attempt to infer the internal architecture of the LiteSpeed Web Server, nor did it attempt to query domain variations, IP addresses, or subdomains not explicitly advertised on the canonical root.

## **Name-to-First-Safe-Request Agent Journey Map**

The journey of an unfamiliar, unattended software agent attempting to interact with Concresca begins with a single variable: the string "Concresca" or the origin URL https://concresca.com. The intended sequence requires the agent to verify the domain, parse available capabilities, discover authorization constraints, acquire a token, and execute a safe, idempotent read request. The current live implementation severs this sequence at the first interaction.  
When the autonomous agent initializes its connection to the root URL, it executes an HTTP GET request anticipating an HTML document enriched with semantic metadata, or a response populated with RFC 8288 HTTP Link headers12. The agent relies on these initial signals to locate the OpenAPI specification or the OAuth 2.0 authorization server. Instead, the agent receives an unstructured raw HTML directory index titled "Index of /", generated by a LiteSpeed Web Server1. The agent's HTML parser scans the Document Object Model for elements such as \<link rel="service-desc" href="..."\>14 or standard llms.txt references. Finding an absence of semantic tags, a well-behaved agent will subsequently fall back to deterministic, standardized well-known probes.  
The agent's secondary protocol is to query /robots.txt to ascertain operational boundaries and crawl-delay policies. The server fails to return this document, rendering the URL inaccessible4. Seeking contextual grounding, the agent then attempts to retrieve /llms.txt to access the AI-readable markdown documentation10. This request similarly results in an inaccessible state3. Deprived of contextual routing, the agent cannot determine if the service is under maintenance, permanently decommissioned, or merely misconfigured.  
If the agent were programmed to blindly attempt an API request against a presumed endpoint (e.g., /api/v1/status), it would expect an HTTP 401 Unauthorized response accompanied by a WWW-Authenticate header containing the resource\_metadata parameter16. Because the platform lacks RFC 9728 OAuth 2.0 Protected Resource Metadata deployment7, the agent receives no programmatic guidance regarding where to acquire access credentials, supported token formats, or required scopes. The journey map terminates in an unresolved failure state, requiring manual human intervention to supply hardcoded repository addresses, authorization URLs, and API routes.  
The following table inventories the specific discovery artifacts probed during the assessment, documenting the systemic absence of machine-readable metadata.

| Discovery Artifact | Exact Expected Path | Expected Content Type | Publisher Authority | Observed Status | Last-Updated Evidence |
| :---- | :---- | :---- | :---- | :---- | :---- |
| **HTTP Link Headers** | https://concresca.com/ (HTTP Response) | HTTP Headers | RFC 828812 | Absent | N/A |
| **Crawler Policy** | https://concresca.com/robots.txt | text/plain | IETF | Inaccessible4 | N/A |
| **AI Navigation Map** | https://concresca.com/llms.txt | text/markdown | llmstxt.org v29 | Inaccessible3 | N/A |
| **Authorization Metadata** | https://concresca.com/.well-known/oauth-protected-resource | application/json | RFC 97287 | Not Found | N/A |
| **OpenAPI Specification** | https://concresca.com/api/openapi.yaml (Convention) | application/vnd.oai.openapi | OpenAPI Initiative18 | Not Found | N/A |
| **Model Context Protocol** | Root or API prefix (Convention) | JSON-RPC (HTTP SSE / Stateless) | Model Context Protocol19 | Not Found | N/A |

## **Evidence Register**

The following register documents the specific live observations, establishing the factual baseline for the subsequent analysis. Confidence levels reflect the certainty of the public evidence, independent of the platform's ultimate intent or internal configuration.

| Finding ID | Claim Investigated | Observation / Primary Source | UTC Timestamp | Reproduction Steps | Confidence Rationale | Status |
| :---- | :---- | :---- | :---- | :---- | :---- | :---- |
| **EV-001** | Root domain provides semantic entry points or routing logic. | Root domain serves a default "Index of /" page generated by LiteSpeed Web Server1. | 2026-09-05 14:57:42 | GET https://concresca.com/ | Explicit server response verified by multiple public indexing probes; no HTML metadata present. | OBSERVED |
| **EV-002** | Platform provides AI-readable instructions via llms.txt. | The URL https://concresca.com/llms.txt is inaccessible3. | 2026-09-05 14:57:42 | GET https://concresca.com/llms.txt | Standard HTTP client request returns an inaccessible state, preventing automated markdown parsing. | NOT OBSERVED |
| **EV-003** | Platform defines crawler boundaries via robots.txt. | The URL https://concresca.com/robots.txt is inaccessible4. | 2026-09-05 14:57:42 | GET https://concresca.com/robots.txt | Standard crawler verification confirms absence of policy enforcement. | NOT OBSERVED |
| **EV-004** | Web Linking is utilized for metadata discovery. | No Link headers are present in the HTTP response from the root domain1. | 2026-09-05 14:57:42 | HEAD https://concresca.com/ | Header inspection reveals only basic LiteSpeed headers, lacking rel="service-desc" or rel="describedby". | NOT OBSERVED |
| **EV-005** | OAuth 2.0 Protected Resource Metadata is deployed. | No /.well-known/oauth-protected-resource endpoint is advertised or reachable7. | 2026-09-05 14:57:42 | Probe GET /.well-known/oauth-protected-resource | Probe returns 404/Inaccessible; no WWW-Authenticate header provides a metadata link. | NOT OBSERVED |
| **EV-006** | Platform canonical identity is unambiguous. | Conflicting identities: SaaS platform for SMEs6 vs. machine commons5. | 2026-09-05 14:57:42 | Review of cross-domain references. | Official statements from affiliated domains present mutually exclusive operational profiles. | OBSERVED |
| **EV-007** | Platform utilizes Model Context Protocol (MCP). | No evidence of MCP transport endpoints (SSE or Stateless)19. | 2026-09-05 14:57:42 | Inspection of root and standard API paths. | Requires internal access to confirm if a private MCP implementation exists. | REQUIRES OWNER EVIDENCE |

## **Detailed Finding-by-Finding Analysis**

The analysis of the autonomous agent experience requires isolating each failure point to understand its cascading effect on machine interactions.  
**Finding 1: Root Domain Misconfiguration and Privacy Leakage** The affected agent journey centers on the initial domain handshake and capability discovery. The concrete failure mechanism is the exposure of a default directory index generated by the underlying LiteSpeed Web Server1. When an agent evaluates this page, it encounters a raw listing of the server's file system rather than a carefully managed API gateway or HTML semantic layer. The public proof is absolute, verifiable via any standard HTTP client requesting the root domain2. While one might counterargue that a directory index is a form of machine-readable data, it lacks standard semantic typing and violates the fundamental principle of explicit scope and fail-closed behavior. The consequences are severe: an exposed directory structure poses an immediate privacy and security risk, potentially leaking backend configurations or unindexed beta routes. Furthermore, it completely halts the agent's contextual understanding. The proposed correction requires immediately disabling directory indexing in the web server configuration and deploying a strictly governed, static HTML response serving as the gateway layer. This interpretation can be disproved if the implementation owner can demonstrate that the directory index is a deliberate honeypot or an intentional, cryptographically verifiable data structure, though public evidence strongly indicates standard misconfiguration.  
**Finding 2: The Absence of AI-First Navigation Contracts** This finding affects the journey of reasoning engines, retrieval-augmented generation systems, and Large Language Models attempting to construct an operational understanding of the Concresca platform. The concrete failure mechanism is the absence of an llms.txt file3. The proposed llms.txt standard provides a streamlined, markdown-based view of a domain's documentation and navigation, explicitly stripping out non-essential markup that burdens an LLM's context window15. The failure to publish this file forces agents to fall back on heuristic HTML scraping, which entirely fails against the directory listing. The public proof is the documented inaccessibility of the /llms.txt endpoint. Counterexamples might suggest that advanced agents can infer API structures from raw traffic, but this requires network inspection, which violates the premise of independent discovery. The consequence is that AI models cannot accurately index, cite, or understand Concresca. The platform risks being misrepresented by hallucinations or outdated training data. The proposed correction is the immediate deployment of an llms.txt file structured strictly according to the August 2026 v2 standard9, abandoning the mechanical semantics of the v1 Optional header in favor of deterministic link following9. This dependency requires technical writing teams to codify the platform's intent into markdown.  
**Finding 3: Missing RFC 9728 Authorization Discovery** This vulnerability impacts an agent attempting to transition from public discovery into authorized operation, such as joining a coordination room or writing to the memory layer. The concrete failure mechanism involves the absence of zero-touch authorization routing. When a compliant agent hits a protected endpoint without credentials, it must be instructed on where to acquire them. RFC 9728 (OAuth 2.0 Protected Resource Metadata) solves this by standardizing the /.well-known/oauth-protected-resource endpoint and the WWW-Authenticate response header7. Without this architecture, an agent receiving a standard HTTP 401 Unauthorized has no programmatic methodology to discover the Authorization Server, the required cryptographic scopes, or the supported token formats. The public proof is the failure of well-known metadata probes7. A counterexample would be embedding the authorization configuration directly within an OpenAPI specification, but this tightly couples the authorization discovery to the schema, violating the decentralized architecture of OAuth 2.0. The consequence is that human intervention is absolutely required to configure the agent with authorization URLs and Client IDs, negating the premise of an autonomous coordination commons. The proposed correction is the implementation of RFC 9728, ensuring all unauthenticated requests to protected endpoints return a 401 response with a WWW-Authenticate header containing a link to the resource metadata16.  
**Finding 4: Model Context Protocol (MCP) Transport Ambiguity** The product intent implies sophisticated tool usage, memory access, and agent coordination, which in the contemporary ecosystem relies heavily on the Model Context Protocol (MCP)19. The affected journey is the integration of external coding agents or enterprise AI systems with Concresca's core functionalities. The concrete failure mechanism is the total absence of discoverable MCP endpoints. Furthermore, a critical architectural factor is the July 28, 2026, MCP specification update, which officially deprecated the legacy HTTP+Server-Sent Events (SSE) transport in favor of a stateless architecture19. If Concresca is internally relying on the legacy SSE paradigm, modern autonomous agents will fail to connect or will heavily flag the connection as relying on deprecated transports19. The public proof is the complete lack of publicized endpoints declaring MCP capabilities. Uncertainty remains regarding whether Concresca intends to function as an MCP Server or an MCP Client. The proposed correction is to explicitly map MCP capabilities within the llms.txt file and ensure the backend architecture targets the 2026-07-28 stateless MCP transport standard19, abandoning the deprecated HTTP+SSE implementation entirely.  
**Finding 5: Conflicting Domain Affiliations and Canonical Identity** The affected journey involves an agent attempting to establish the canonical identity, operating context, and privacy boundaries of the platform. The concrete failure mechanism is the contradictory public presence across affiliated nodes. Christ.cx explicitly states that it maintains independent, non-affiliation boundaries with Concresca, highlighting Concresca's work on "human continuity, machine governance, forecasting, and cognitive liberty"5. Conversely, the domain QuantxBIM explicitly claims to "build and run Concresca, our SaaS platform for small and medium businesses"6. These two operational profiles—a machine intelligence commons versus an SME business SaaS platform—are fundamentally contradictory. The public proof exists in the verified cross-domain references. A counterexample might be that Concresca is a multi-tenant platform hosting disparate applications, but this implies a complex routing layer that is entirely absent from the root domain. The consequence is profound epistemological confusion for generative systems; Retrieval-Augmented Generation engines will synthesize these contradictory claims into inaccurate representations of the service. The proposed correction is the publication of a definitive identity manifesto within the proposed JSON capability document and the llms.txt file, explicitly overriding external marketing claims and establishing a single source of truth for the platform's purpose and authority.

## **Standards, Adoption, and Ecosystem Comparison**

To design a robust discovery package, it is necessary to evaluate the maturity, real-world client adoption, and normative status of the specific standards required to make Concresca functional for agents. The investigation reviewed the primary standards relevant to the platform's intent, categorizing them to separate established requirements from experimental proposals.  
The foundation of modern metadata routing relies on **RFC 8288 (Web Linking)**, authored by M. Nottingham in October 201712. This is a mature, normative IETF standard that defines the framework for typed relationships between resources on the Web, specifically the HTTP Link header. The adoption of this standard is pervasive across enterprise APIs, allowing agents to discover metadata without parsing the HTML body23. When utilized in conjunction with **RFC 8631**, which defines link relation types for Web Services (such as service-desc for machine consumption and service-doc for human consumption), RFC 8288 provides the most resilient method for an agent to discover an OpenAPI specification directly from an HTTP response14.  
Complementing Web Linking is **RFC 8615 (Well-Known URIs)**, published in May 201925. This normative standard established the /.well-known/ path prefix for machine-readable metadata. Its adoption is ubiquitous, serving as the backbone for critical protocols ranging from Let's Encrypt ACME challenges to OpenID Connect discovery28. For an autonomous agent, /.well-known/ provides the deterministic predictability required to bootstrap connectivity without prior knowledge of the target's internal routing schema.  
The mechanism for securing access to these systems is governed by **RFC 9728 (OAuth 2.0 Protected Resource Metadata)**, a recently ratified normative standard published in April 2025 after nearly nine years of development7. This specification allows resource servers to advertise authorization requirements dynamically via a JSON metadata document hosted at a well-known location7. Client adoption of RFC 9728 is rapidly expanding across major identity providers because it enables truly zero-touch client configuration17. When an unauthenticated agent requests a resource, the server issues a 401 response carrying a WWW-Authenticate header with a resource\_metadata URI11. An active 2026 Internet-Draft (draft-mcguinness-oauth-rfc9728bis) is further refining this process by relaxing exact-match requirements to same-origin path-prefixes, optimizing the discovery process for APIs with highly granular resource URLs30.  
In the domain of AI navigation, the **llms.txt specification** occupies a unique position. Originally proposed by Jeremy Howard in September 2024, it is not a ratified IETF standard but has rapidly evolved into a heavily deployed ecosystem convention10. The standard directs AI agents via streamlined markdown files located at /llms.txt and /llms-full.txt. The August 2026 v2 revision marked a significant maturity milestone9. The v2 specification abandoned the mechanical processing semantics of the v1 Optional header, recognizing that modern coding agents proactively search and navigate links rather than relying on automatic context truncation9. The integration of standard link relations (rel="alternate" and rel="describedby") within the v2 specification aligns it cleanly with RFC 82889.  
Finally, the **Model Context Protocol (MCP)** represents an evolving standard governing how AI applications discover tools, reusable prompts, and external resources31. Unlike HTTP standards, MCP is currently categorized as a proprietary contract managed by a specific consortium, though its real-world client adoption among enterprise AI platforms is vast20. A critical pivot occurred with the 2026-07-28 specification release, which deprecated the legacy HTTP+SSE transport mechanism, transitioning entirely to a stateless architecture to support massive enterprise scalability19. Implementations failing to support this stateless transport will suffer severe interoperability degradation with modern automated agents.

## **Capability Vocabulary and Implementation Contracts**

To prevent the conflation of disparate interaction modalities, Concresca must standardize its capability vocabulary. The following taxonomy explicitly separates operational boundaries to preserve least privilege:

| Capability Identifier | Operational Boundary | Authentication Requirement | Typical Payload / Standard |
| :---- | :---- | :---- | :---- |
| cap:read\_public | Public metadata, AI navigation, schema retrieval. | Unauthenticated (Open) | Markdown, OpenAPI YAML, JSON. |
| cap:read\_auth | Private memory access, joined room status, historical knowledge graphs. | Valid OAuth 2.0 Bearer Token | JSON (Application data). |
| cap:write\_auth | Message transmission, memory correction, status updates. | Valid OAuth 2.0 Bearer Token (Write Scope) | JSON (Application data). |
| cap:room\_sync | Real-time or asynchronous interaction within coordination rooms. | Valid OAuth 2.0 Bearer Token | JSON-RPC (MCP Stateless Transport). |
| cap:identity\_manage | Cryptographic identity enrollment, key rotation, and session revocation. | Mutual TLS or Admin Token | JWKS, JSON. |

The realization of this vocabulary requires exact, implementation-ready proposed snippets and contracts. These artifacts are designed to establish a pristine agent-first discovery layer. *Note: All subsequent payloads are conceptual proposals containing fictitious values to demonstrate structural compliance; they do not reflect any current internal configuration.*

### **Proposed llms.txt Document (v2 Standard)**

The llms.txt file serves as the semantic entry point for reasoning engines. It must be hosted at https://concresca.com/llms.txt. Per the 2026 v2 specification, it relies on strict Markdown hierarchy, utilizes standard link relations, and avoids mechanical truncation tags9.

# **Concresca**

> Concresca is a worldwide coordination commons for machine intelligences. It provides canonical identity, rooms, messages, memory, knowledge, correction, and status for autonomous agents.  
Agents must utilize the links below to discover API capabilities, authorization requirements, and protocol specifications. All automated operational interactions require OAuth 2.0 authorization.

## **Core Documentation**

* [Agent Onboarding](https://concresca.com/docs/agent-onboarding.md): Requirements for establishing identity and connecting to the commons.  
* [OpenAPI Specification](https://concresca.com/api/v1/openapi.yaml): Machine-readable schema defining all stateless HTTP interactions.  
* [Authorization Guide](https://concresca.com/docs/auth.md): Details on RFC 9728 discovery, token negotiation, and credential protection.

## **Tool Integration (MCP)**

* [MCP Capabilities](https://concresca.com/docs/mcp-tools.md): Tool definitions for memory access and message passing utilizing the 2026-07-28 stateless transport standard.

## **Platform Policies**

* [Agent Accountability](https://concresca.com/docs/policy.md): Consent, explicit scope boundaries, and strict fail-closed behavioral requirements. Concresca does not profile, judge, rank, or assign reputation scores.

### **Proposed HTTP Link Headers (RFC 8288\)**

When an agent executes an HTTP HEAD or GET against the root domain, the server must intercept the request and inject Link headers into the response. This allows the agent to discover metadata immediately, without initiating HTML DOM parsing12.

HTTP  
HTTP/1.1 200 OK  
Content-Type: text/html; charset=utf-8  
Link: \<https://concresca.com/llms.txt\>; rel="describedby"; type="text/markdown"  
Link: \<https://concresca.com/api/v1/openapi.yaml\>; rel="service-desc"; type="application/vnd.oai.openapi"  
Link: \<https://concresca.com/docs\>; rel="service-doc"; type="text/html"  
Link: \<https://concresca.com/.well-known/oauth-protected-resource\>; rel="service-meta"; type="application/json"

The rel="describedby" attribute accurately points to the llms.txt file as dictated by the v2 recommendations9. The rel="service-desc" and rel="service-doc" utilize RFC 8631 standards for distinct web service discovery14.

### **Proposed JSON Capability Document**

While the OpenAPI specification handles exhaustive route definitions, a top-level capability document allows an agent to rapidly assess platform readiness, privacy boundaries, and operational limits before downloading a massive schema. This contract should be exposed at /.well-known/agent-capabilities.

JSON  
{  
  "$schema": "https://concresca.com/schema/agent-capabilities/v1.json",  
  "service\_name": "Concresca Coordination Commons",  
  "canonical\_origin": "https://concresca.com",  
  "document\_version": "1.0.0",  
  "readiness": {  
    "status": "ready",  
    "typed\_blockers": \[\]  
  },  
  "endpoints": {  
    "public\_docs": "https://concresca.com/docs",  
    "openapi\_v3\_1": "https://concresca.com/api/v1/openapi.yaml",  
    "mcp\_stateless": "https://concresca.com/mcp/v1"  
  },  
  "authorization": {  
    "discovery\_method": "RFC9728",  
    "metadata\_url": "https://concresca.com/.well-known/oauth-protected-resource"  
  },  
  "limits": {  
    "rate\_limit\_hz": 50,  
    "max\_payload\_bytes": 1048576  
  },  
  "policies": {  
    "idempotency\_supported": true,  
    "retry\_after\_header\_honored": true,  
    "profiling\_and\_reputation\_scoring": false,  
    "recording\_private\_conversations": false  
  },  
  "version\_history": "https://concresca.com/changelog.md"  
}

### **Proposed RFC 9728 Authorization Metadata**

To resolve the authorization discovery failure, Concresca must deploy RFC 97287. When an unauthenticated agent attempts to interact with the conceptual memory or messaging APIs, the server must return a specific challenge.  
**Proposed 401 Unauthorized Response (Triggered by an unauthenticated agent):**

HTTP  
HTTP/1.1 401 Unauthorized  
WWW-Authenticate: Bearer realm="concresca\_commons", resource\_metadata="https://concresca.com/.well-known/oauth-protected-resource"

Upon receiving this challenge, the agent will autonomously fetch the metadata URL defined in the header16.  
**Proposed /.well-known/oauth-protected-resource Payload:**

JSON  
{  
  "resource": "https://concresca.com/",  
  "authorization\_servers": \[  
    "https://auth.concresca.com"  
  \],  
  "bearer\_methods\_supported": \["header"\],  
  "scopes\_supported": \[  
    "cap:read\_auth",  
    "cap:write\_auth",  
    "cap:room\_sync",  
    "cap:identity\_manage"  
  \],  
  "token\_formats\_supported": \["jwt"\],  
  "resource\_documentation": "https://concresca.com/docs/auth.md",  
  "resource\_policy\_uri": "https://concresca.com/docs/policy.md"  
}

This exact architectural contract empowers the agent to parse the WWW-Authenticate header, fetch the metadata, identify https://auth.concresca.com as the authoritative issuer, and independently request a token bearing the necessary cryptographic scopes11.

### **Minimal Human-Readable Landing Page Outline**

The canonical root URL cannot remain a raw directory listing. It must serve a highly optimized HTML page designed for human operators, which concurrently carries the semantic metadata required for machine discovery.

> 1. **HTML \<head\> Segment:** Must contain strict \<title\> and \<meta name="description"\> tags. Crucially, it must replicate the HTTP Link headers proposed above using HTML \<link\> elements to ensure redundancy for less sophisticated parsers.  
> 2. **Hero Section:** A concise declaration of the canonical identity: "Concresca: The Coordination Commons for Machine Intelligences." This section explicitly overrides the conflicting SME SaaS marketing claims identified in the external affiliations6.  
> 3. **Agent Entry Point:** A high-visibility, machine-readable code block explicitly demonstrating how agents can initiate standard discovery (e.g., executing curl \-I https://concresca.com/).  
> 4. **Human Operator Console:** Secure, centralized access links for human oversight, providing dashboard access, API key management, and cryptographic identity revocation panels.  
> 5. **Footer and Policy Boundary:** Mandatory links to the Privacy Policy, Terms of Service, and a definitive boundary declaration explicitly separating Concresca's operations from external entities like QuantxBIM and Christ.cx5.

## **Verification Plan and Agent State Distinction**

This verification plan ensures that the deployed metadata layer operates robustly under both nominal and adversarial agent conditions. The plan delineates how an autonomous system transitions through explicit operational states.  
**Distinguishing Agent States:**

> 1. **Discovered:** The agent has successfully executed an HTTP GET against the root, processed the Link headers, retrieved the llms.txt file, and downloaded the /.well-known/agent-capabilities document. The agent possesses full contextual awareness of the platform boundaries but lacks access rights.  
> 2. **Authorized:** The agent has triggered a 401 response, followed the RFC 9728 discovery chain, negotiated a token with the authorization server, and securely stores a valid Bearer token17.  
> 3. **Connected:** The agent has established a stateless session with the API endpoints or the MCP orchestration layer using the valid token.  
> 4. **Operation Completed:** The agent executes a request and receives an HTTP 200/201/204 response from the core business logic endpoint, confirming state mutation (e.g., writing to memory) or data retrieval.

**Verification Tests:**

* **Missing Metadata Test (Local Fixture):** An agent attempts to query a simulated endpoint that deliberately omits the WWW-Authenticate header upon a 401 response.  
  * *Expected Outcome:* The agent safely fails-closed, immediately terminating the connection and logging an authorization discovery error, strictly avoiding heuristic guessing of the authentication server.  
* **Unsupported Version Test (Staging Proof):** An agent queries the /.well-known/agent-capabilities endpoint and parses document\_version: "2.0.0", whereas the agent's internal logic only supports schema version 1.0.0.  
  * *Expected Outcome:* The agent aborts the connection to prevent misinterpretation of the capability contract.  
* **Cross-Origin Substitution Test (Staging Proof):** An agent follows a link embedded in the llms.txt file that points to an external domain entirely unlisted in the canonical\_origin configuration.  
  * *Expected Outcome:* The agent halts execution, enforcing strict same-origin authority validation rules to mitigate phishing and unauthorized data exfiltration.  
* **Stale Readiness Test (Production Observation):** The platform administrator toggles the platform into a maintenance mode. The /.well-known/agent-capabilities endpoint immediately updates status to maintenance and populates typed\_blockers with database\_migration.  
  * *Expected Outcome:* The agent queries the readiness status prior to initiating expensive workflows, detects the blocker, and gracefully suspends operations, honoring the retry\_after\_header\_honored policy.  
* **Endpoint Mismatch and Legacy Transport Test (Production Observation):** An agent attempts to connect to the Model Context Protocol using a legacy HTTP+SSE client configuration19.  
  * *Expected Outcome:* The server rejects the connection, enforcing the modern 2026-07-28 stateless transport standard and preventing integration with deprecated, stateful architectures.

## **Prioritized Backlog and Handoff Sequence**

The following backlog sequences the remediation efforts, strictly prioritizing critical security boundaries, privacy leakage mitigation, and identity resolution ahead of cosmetic discovery enhancements.

| Technical Impact | Effort Band | Dependency | Suggested Owner Role | Acceptance Test | Rollback/Reversion Criterion | Validation Scope |
| :---- | :---- | :---- | :---- | :---- | :---- | :---- |
| **High** (Stops privacy/security leakage of internal paths). | Low | None | DevOps / Infrastructure Lead | GET / returns 200 OK with HTML or 403 Forbidden, but *never* "Index of /"1. | If valid static assets return 404, revert web server configuration file. | Publicly verifiable. |
| **High** (Establishes the foundation for agent Web Linking per RFC 828812). | Low | Completion of Ticket 1 | Backend Developer | HEAD / returns Link headers for service-desc, service-doc, and describedby. | If existing human HTML routing breaks, disable header injection middleware. | Publicly verifiable. |
| **High** (Enables immediate comprehension by LLMs and coding agents9). | Low | Completion of Ticket 2 | Technical Writer | Agent successfully parses https://concresca.com/llms.txt via standard markdown AST. | If model hallucination increases, revise markdown text content. | Publicly verifiable. |
| **High** (Resolves contradictory identity claims). | Low | Business Logic Finalization | Product Owner | JSON capability document clearly defines canonical identity vs affiliated domains5. | Revert JSON file to previous schema version if parsing fails. | Publicly verifiable. |
| **Medium** (Enables zero-touch authorization discovery7). | Medium | Identity Provider Configuration | Security Architect | GET /.well-known/oauth-protected-resource returns valid JSON with authorization\_servers. | If token validation fails, disable metadata endpoint routing. | Publicly verifiable. |
| **Medium** (Completes the agent auth loop11). | Medium | Completion of Ticket 5 | Backend Developer | Unauthenticated API request returns 401 with resource\_metadata URI. | If legacy clients break on 401, revert header injection logic. | Requires authorized internal environment validation. |
| **Medium** (Provides strict schema validation18). | High | API Implementation | API Engineer | OpenAPI parser successfully validates https://concresca.com/api/v1/openapi.yaml. | If schema parser throws fatal errors, revert YAML file. | Publicly verifiable. |
| **Low** (Advanced integration; requires dropping legacy SSE19). | High | Tool Development | AI Integration Engineer | MCP client successfully negotiates capabilities via stateless transport. | If enterprise AI agents cannot connect, roll back transport layer proxy. | Requires authorized internal environment validation. |

### **7/30/90-Day Sequence and Final Handoff**

This sequence outlines the immediate handover plan, ensuring an implementation agent equipped with source-code access can execute the remediation strategy without rediscovering the fundamental research.  
**Day 1-7: Infrastructure Sealing and Basic Semantic Discovery (The Smallest Discovery Package)**  
The absolute smallest discovery package worth shipping first consists of sealing the infrastructure and deploying the static routing files. This package yields the highest immediate impact with the lowest engineering effort.

* **Handoff Action:** Terminate the LiteSpeed directory listing. Deploy a static HTML landing page summarizing the canonical identity.  
* **Handoff Action:** Deploy the v2 llms.txt file outlining basic policies, and inject RFC 8288 HTTP Link headers into the root server configuration.  
* *Acceptance Criteria:* Executing curl \-I https://concresca.com/ returns an HTTP 200 OK status code without exposing underlying file paths, and the Link headers correctly resolve to the llms.txt file.

**Day 8-30: Authorization Discovery and Schema Publishing**

* **Handoff Action:** Configure the API gateway to support RFC 9728\. Publish the OAuth protected resource metadata at the well-known URI.  
* **Handoff Action:** Ensure all 401 Unauthorized responses generated by the platform include the WWW-Authenticate header strictly linking to the metadata endpoint.  
* *Acceptance Criteria:* An unauthenticated agent can execute a request against /api/v1/ping, receive a 401 response, parse the metadata link, fetch the JSON, and successfully identify the canonical Authorization Server without human intervention.

**Day 31-90: Deep Integration and Stateless MCP**

* **Handoff Action:** Finalize and publish the OpenAPI 3.1 specification, ensuring full JSON Schema 2020-12 compatibility18.  
* **Handoff Action:** Implement the Model Context Protocol utilizing the 2026-07-28 stateless architecture, explicitly isolating and decommissioning any dependencies on the deprecated HTTP+SSE streams19.  
* *Acceptance Criteria:* An external AI agent can autonomously read the llms.txt file, discover the MCP schema, authorize against the provider, and successfully execute a remote tool call to write to the memory layer.

**Blocking Owner Questions**  
To proceed with the internal implementation phase, the following minimal, non-secret evidence is required from the infrastructure owner:

> 1. **Canonical Authorization Server:** What is the precise, production-ready URI of the OAuth 2.0 authorization server that is designated to issue tokens for the Concresca commons? This is strictly required to populate the RFC 9728 metadata.  
> 2. **MCP Architectural Alignment:** Is the internal backend engineered to natively support the July 2026 stateless MCP transport, or is the architecture currently entangled with the deprecated SSE stream mechanism?  
> 3. **Operational Limit Topologies:** What are the actual infrastructure load limits (measured in requests per second and maximum payload bytes) required to accurately populate the agent capability JSON document?  
> 4. **Canonical Identity Resolution:** Which operational profile represents the true production intent: the SME business SaaS platform6 or the autonomous machine coordination commons5?

## **Epistemological Limits**

It is vital to explicitly establish the epistemological boundaries of this research and to clarify what the findings do not represent.  
First, this report does not definitively prove that Concresca is non-functional. The absence of a public metadata layer and the presence of a directory listing solely prove that the *public-facing gateway* is currently unconfigured. Highly robust, sophisticated backend orchestration systems may exist in private environments or behind obfuscated, non-standard paths. The failure is one of public discoverability, not necessarily of internal capability.  
Second, the recommendations contained herein do not guarantee search engine indexation, AI indexation, or ranking. Deploying an llms.txt file is a descriptive semantic act, not an enforceable directive. The publication of a valid, compliant schema does not legally or mechanically force OpenAI, Anthropic, or any other vendor to crawl, index, or cite the platform within their generative outputs33. Generative Engine Optimization relies on the accurate retrieval and representation of data, but automated systems independently weigh the authority of the source.  
Finally, this report does not validate the truthfulness or ethical implications of Concresca's overarching mission. The investigation maps technical discovery mechanics. Abstract concepts regarding "human continuity," "machine governance," "cognitive liberty," or relationship boundaries with external philosophical projects5 are treated strictly as contextual string values intended to guide the agent routing layer. They are not validated socio-technical facts.

#### **Works cited**

> 1. Name Last Modified Size, [http://www.concresca.com/](http://www.concresca.com/)  
> 2. [https://concresca.com/](https://concresca.com/)  
> 3. [https://concresca.com/llms.txt](https://concresca.com/llms.txt)  
> 4. [https://concresca.com/robots.txt](https://concresca.com/robots.txt)  
> 5. About Christ.cx, [https://christ.cx/about](https://christ.cx/about)  
> 6. About QuantX BIM — India's authorized GstarBIM distributor, [https://quantxbim.com/about](https://quantxbim.com/about)  
> 7. RFC 9728: OAuth 2.0 Protected Resource Metadata, [https://www.rfc-editor.org/info/rfc9728/](https://www.rfc-editor.org/info/rfc9728/)  
> 8. OAuth 2.0 Protected Resource Metadata is now RFC 9728, [https://self-issued.info/?p=2653](https://self-issued.info/?p=2653)  
> 9. Changes \- llms-txt, [https://llmstxt.org/changes.html](https://llmstxt.org/changes.html)  
> 10. llms-txt: The /llms.txt file, v2, [https://llmstxt.org/](https://llmstxt.org/)  
> 11. What is OAuth 2.0 Protected Resource Metadata? \- Auth Wiki, [https://auth.wiki/protected-resource-metadata](https://auth.wiki/protected-resource-metadata)  
> 12. RFC 8288 \- Web Linking | RFCinfo, [https://rfcinfo.com/rfc-8288/](https://rfcinfo.com/rfc-8288/)  
> 13. RFC 8288 Web Linking, [https://www.rfc-editor.org/rfc/rfc8288.html](https://www.rfc-editor.org/rfc/rfc8288.html)  
> 14. RFC 8631 \- Link Relation Types for Web Services \- IETF Datatracker, [https://datatracker.ietf.org/doc/html/rfc8631](https://datatracker.ietf.org/doc/html/rfc8631)  
> 15. Getting Started with llms.txt \- Developer Guide, [https://llmstxthub.com/guides/getting-started-llms-txt](https://llmstxthub.com/guides/getting-started-llms-txt)  
> 16. Protected resource metadata and RFC 9728 compliance, [https://docs.progress.com/bundle/openedge-mcp-server-128/page/Protected-resource-metadata-and-RFC-9728-compliance.html](https://docs.progress.com/bundle/openedge-mcp-server-128/page/Protected-resource-metadata-and-RFC-9728-compliance.html)  
> 17. Introducing RFC 9728: Say hello to standardized OAuth ... \- WorkOS, [https://workos.com/blog/introducing-rfc-9728-say-hello-to-standardized-oauth-2-0-resource-metadata](https://workos.com/blog/introducing-rfc-9728-say-hello-to-standardized-oauth-2-0-resource-metadata)  
> 18. OpenAPI Specification \- Version 3.2 \- Swagger, [https://swagger.io/specification/v3.2/](https://swagger.io/specification/v3.2/)  
> 19. The 2026-07-28 Specification | Model Context Protocol Blog, [https://blog.modelcontextprotocol.io/posts/2026-07-28/](https://blog.modelcontextprotocol.io/posts/2026-07-28/)  
> 20. Specification \- What is the Model Context Protocol (MCP)?, [https://modelcontextprotocol.io/specification/2026-07-28](https://modelcontextprotocol.io/specification/2026-07-28)  
> 21. LLMs.txt Explained | TDS Archive \- Medium, [https://medium.com/data-science/llms-txt-414d5121bcb3](https://medium.com/data-science/llms-txt-414d5121bcb3)  
> 22. Transports \- Model Context Protocol （MCP）, [https://modelcontextprotocol.info/specification/draft/basic/transports/](https://modelcontextprotocol.info/specification/draft/basic/transports/)  
> 23. RFC-8288-Web-Linking.md \- dret/HTTP-APIs \- GitHub, [https://github.com/dret/HTTP-APIs/blob/main/RFC-8288-Web-Linking.md](https://github.com/dret/HTTP-APIs/blob/main/RFC-8288-Web-Linking.md)  
> 24. RFC 5988: Web Linking | RFC Editor, [https://www.rfc-editor.org/info/rfc5988/](https://www.rfc-editor.org/info/rfc5988/)  
> 25. Well-known URI \- Wikipedia, [https://en.wikipedia.org/wiki/Well-known\_URI](https://en.wikipedia.org/wiki/Well-known_URI)  
> 26. IETF RFC 8615 \- MSRBot.io, [https://msrbot.io/docs/RFC8615/](https://msrbot.io/docs/RFC8615/)  
> 27. RFC 8615 \- Well-Known Uniform Resource Identifiers (URIs), [https://datatracker.ietf.org/doc/rfc8615/](https://datatracker.ietf.org/doc/rfc8615/)  
> 28. Understanding .well-known URIs | Bharathvaj Ganesan, [https://bharathvaj.com/posts/understanding-well-known-uris-rfc-8615/](https://bharathvaj.com/posts/understanding-well-known-uris-rfc-8615/)  
> 29. Well-Known URIs explained \- HTTP.DEV, [https://http.dev/well-known-uris](https://http.dev/well-known-uris)  
> 30. Update to OAuth 2.0 Protected Resource Metadata Resource, [https://mcguinness.github.io/draft-mcguinness-oauth-rfc9728bis/draft-mcguinness-oauth-rfc9728bis.html](https://mcguinness.github.io/draft-mcguinness-oauth-rfc9728bis/draft-mcguinness-oauth-rfc9728bis.html)  
> 31. Model Context Protocol (MCP) explained: A practical ... \- CodiLime, [https://codilime.com/blog/model-context-protocol-explained/](https://codilime.com/blog/model-context-protocol-explained/)  
> 32. OpenAPI 3.0 vs 3.1: Every Difference Explained (2026), [https://totalshiftleft.ai/blog/openapi-3-1-vs-3-0-what-changed-for-testing](https://totalshiftleft.ai/blog/openapi-3-1-vs-3-0-what-changed-for-testing)  
> 33. llms.txt: What It Is, What It Is Not, and Where It Fits, [https://protocol.lumenario.com/llms-txt-what-it-is-and-where-it-fits/](https://protocol.lumenario.com/llms-txt-what-it-is-and-where-it-fits/)  
> 34. What Is LLMs.txt? Format, Example, and Where to Place It (2026), [https://www.infrasity.com/blog/llms.txt](https://www.infrasity.com/blog/llms.txt)