CPX.AGENCYCHYPHNXIdeas. People. Products.

CPX / CHYPHNX · Developer access

Proof at
the boundary.

Understand the interface. Evaluate the result. Keep the implementation private.

Versioned contracts make expectations inspectable. Synthetic fixtures make the integration tangible. Access to a proprietary system requires a separate, bounded evaluation.

Explore the reference
Public referenceContract v0.1.0 · proposalNo live product API

01 / Contract explorer

A small, inspectable proof.

Compare two sets of synthetic binary labels. This reference computes a confusion matrix and agreement metrics in this browser. It does not execute a CPX product, authenticate a user, or measure a proprietary system.

POST/v1/reference/classificationProposed path
Browser only

Request

application/json

1–128 labels per array. Integers 0 or 1 only. Matching lengths. Maximum 8 KiB. Use synthetic data only.

Response

Awaiting a local run
{
  "status": "awaiting_local_run",
  "notice": "No request will be sent."
}

Ready. Load an example or edit the request.

Reference result, not a product benchmark. These are user-supplied labels. A score of 1.0 shows agreement within this sample; it does not establish security, accuracy on new data, or production readiness.

No network calls · no credentials · no stored payloadsProposed OpenAPI 3.1 Read reference code

02 / Evaluation progression

Access follows evidence.

A useful evaluation defines what will be measured, what can fail, and where the boundaries sit. A public reference is the starting point.

  1. 01
    Available here · proposed

    Inspect the contract.

    Review request shape, response semantics, validation rules and versioning. The downloadable contract is a proposal; its reserved example hostname is not a deployed endpoint.

  2. 02
    Available here · synthetic

    Exercise a reference.

    Run bounded inputs against the public fixture. Check handling of malformed payloads and undefined metrics before discussing a product integration.

  3. 03
    Separate invitation required

    Evaluate a real system.

    A future product evaluation needs an approved scope, provisioned identity, isolated data, explicit quotas and recorded evidence. No such access is granted by this page.

  4. 04
    Separate written authorization

    Test the boundary.

    Agree on targets, load, timing, stop conditions and recovery before stress or adversarial testing. The public website is not an authorized stress-test target.

03 / Disclosure model

An open interface.
A private engine.

Publish what an integrator needs to use and assess a service. Release selected client libraries or reference tooling only after a separate review. Keep proprietary implementation, training material, operational policy and secrets behind controlled service boundaries.

Browser code is delivered to the visitor and can be inspected. This fixture is intentionally public. Proprietary execution belongs on a separately secured backend, not in a minified script.

Public
Versioned contracts, sample payloads, reference behavior, limitations and approved evidence.
Selected release
Reviewed SDKs and integration examples with explicit licensing. None are implied to exist by this proposal.
Controlled access
Product evaluation endpoints, scoped credentials, quotas and tenant isolation—once implemented and verified.
Private
Proprietary source, model internals, restricted datasets, deployment configuration and secrets.

Explore the portfolio

Every system needs
its own proof.

Public descriptions identify program direction. Each product must establish its own maturity, deployment status and evaluation evidence.

Review the system registry