Certification Policy

1. Who issues the badge

In short: Suncly issues it, and a named person at Suncly decides.

The Suncly Certified badge is issued by [legal entity name: to be supplied], Tallinn, Estonia ("Suncly", "we"). Each certification decision is taken by a named Suncly reviewer, recorded on the record: [who decides, from founder inputs block 6: to be supplied].

2. A private, voluntary programme

In short: It is our statement about a test we ran. It is neither official nor accredited, and it certifies nothing under any law or standard.

Suncly Certified is a private, voluntary evaluation programme run by Suncly. It is not an accredited conformity assessment, not a certification under any law or standard, and not a mark of approval by any public body, standards body, foundation or vendor. The badge does not mean "compliant", "secure", "safe" or "approved by". It does not relate to the EU Artificial Intelligence Act's conformity assessment, CE marking or notified bodies, and we never describe it as such.

Certification is Suncly's statement that a named agent version met a named, published set of criteria on a date, on a sandbox endpoint. It is not the customer's approval, not a rating, not a score and not a tier. The Suncly software itself never approves or blocks an agent; the programme's decision is a separate, human decision by Suncly about the evidence.

3. The criteria and their version

In short: Every record names the criteria version it was tested against. No criteria are published yet.

Criteria are published here with a version number before any record is issued under them, and a record keeps its criteria version until it expires. No criteria have been adopted. A first profile, built only from checks that exist in the Suncly software today, is in founder review; it will be published here with its version number if and when it is accepted, and nothing is certified before then.

4. What is tested, and what is not

In short: The record says exactly which agent, operator, endpoint, card, protocol version, date and run counts. The gaps are listed too.

Each record states: the agent and its operator; the sandbox endpoint tested; the card hash and the A2A protocol version; the date of the evaluation; the number of test cases and runs, with the pass, fail and inconclusive counts; the criteria version; and the Suncly reviewer.

Each record also states what was not tested, taken from the evaluation report. In the current version that always includes: the production endpoint, which is never called; whether the content of an answer is correct in meaning; prompt-injection, undeclared-behaviour and failure-handling probes; A2A bindings other than JSON-RPC; and declared capabilities no test exercised, such as streaming or push notifications.

5. Validity, expiry and re-tests

In short: A record is valid for a stated period or until the card changes, whichever comes first.

A record is valid for [validity period, from founder inputs block 6: to be supplied], or until the agent's card hash changes, whichever comes first. An expired record stays visible, marked expired.

A re-test is required when: [re-test triggers, from founder inputs block 6: to be supplied]. A changed Agent Card (a different hash) always ends the record's validity.

6. Suspension and revocation

In short: We can pause or withdraw a record, and we say why on the record.

Suncly may suspend a record while it investigates a report that the agent's behaviour contradicts the record, or that the operator breached this policy. Suncly revokes a record when the investigation confirms the report, when the operator used the badge in a prohibited way and did not correct it within fourteen days of notice, or when the evidence behind the record is found to be invalid. A suspended or revoked record stays visible with its status and the date, and the operator must stop displaying the badge at once.

7. The public record

In short: The record page is the single source of truth. The badge is only a pointer to it.

Every issued badge has a short record id and a public page at suncly.com/certified/<id>. The record page is the only authoritative statement of what was certified, when, under which criteria, with which gaps, and whether the record is valid. If a badge and a record disagree, the record wins. The limits of certification appear on the record page itself.

8. Licence to display the badge

In short: You may show the badge for the certified version, while the record is valid, unaltered and linked to its record.

While a record is valid, Suncly grants its operator a non-exclusive, non-transferable, revocable licence to display the Suncly Certified badge, in the files provided at /certified, only in connection with the certified agent version, only while the record is valid, unaltered, and always linked to the record page. The licence ends when the record expires, is suspended or is revoked, and the operator must then remove the badge within seven days. No other right in the Suncly name or marks is granted.

9. Prohibited uses and words

In short: Do not use the badge to claim more than the record says.

• Do not alter the badge: no recolouring, cropping, rotation, effects, added words, tiers, stars or laurels.
• Do not display it for a different agent, a different version, or a production endpoint.
• Do not place it next to, or describe it with, the words "guaranteed", "secure", "safe", "compliant", "approved by", "official", "accredited" or "certified by the Linux Foundation", or any statement that it is a legal, security or regulatory certification.
• Do not imply that Suncly, the Linux Foundation, the A2A project or any vendor endorses the agent or its operator.
• Do not use it in a way that suggests the customer's own approval decision has been made for them.

10. No pay-to-pass

In short: The badge is free, and the outcome does not change what you pay.

The badge itself costs nothing. Where Suncly charges for usage of the Suncly API, the fees are the same whether an agent passes or fails, and no fee is charged for the certification decision. Nobody at Suncly is paid by the outcome of a decision.

11. Corrections and appeals

In short: Tell us what is wrong. How fast we answer is not yet set.

An operator, or anyone who relies on a record, may ask for a correction or appeal a decision by writing to [corrections and appeals contact, from founder inputs block 6: to be supplied]. Response times: [acknowledgement and answer periods, to be set by the founders: to be supplied]. We correct a record when the facts on it are wrong, and we say on the record what was corrected and when. Where we learn that information on a record is incorrect, we correct or withdraw it without being asked.

12. Changes

In short: We version this policy and give notice of changes.

Changes to this policy are published here with a new version number and effective date. A change to the criteria creates a new criteria version; existing records keep their version until they expire. Operators with a valid record are notified by e-mail at least thirty days before a change that affects their licence to display the badge.