Validation lane
Received does not mean reviewed.
Return a clear validation result and preserve the owner of the next review step.
ControlQuill API
Bring compliance records into the systems that produce the work.
Evaluate a bounded evidence-intake or status workflow while preserving source, ownership, validation, and review context.
Example event receiptCQ-RX-018
sourceapproved_internal_system
objectevidence_reference
received_atrecorded_timestamp
validationcontext_review_required
linked_requestcontrol_request_reference
review_state△ accountable_owner_needed
Start with a bounded workflow.
A useful integration has a defined source, event, object, owner, expected response, and failure path. Begin with one repeatable exchange rather than treating an API as a promise to automate the entire compliance program.
Source
Approved system
Event
Defined trigger
Object
Known record type
Owner
Accountable party
Response
Receipt or status
Failure
Visible recovery path
Evaluate the exchange by its record.
Evidence context
Assess whether a record or reference can carry the control, period, owner, and source metadata needed for review.
Request status
Determine which states can be surfaced in an operational system without overstating a review conclusion.
Internal link
Evaluate how a ticket, asset, vendor, training record, or identifier relates to the ControlQuill record.
Review handoff
Route an event or change into a queue for a person to evaluate.
Processing history
Examine receipt, validation, relationship, and error context for troubleshooting and auditability.
Design for accountable failure.
An integration needs explicit authentication, authorization, validation, retry, duplicate handling, and error behavior. A failed or partial submission should remain visible and should not silently change a compliance status.
Error lane
Failure remains inspectable.
Keep the error context, recovery owner, and expected retry behavior visible.
Sensitive-material boundary
Keep secrets and production evidence out of public channels.
Technical evaluation should use approved test data and a documented access process. Do not send credentials, production evidence, personal data, or confidential security records to the public contact address.
Technical questions for evaluation.
- Which objects and actions are available?
- How is access authenticated and scoped?
- Which formats and file sizes are accepted?
- How are retries and duplicate submissions handled?
- Are event notifications, pagination, and versioning supported?
- How are errors and processing receipts returned?
- What retention and deletion behavior applies?
- How does the workflow preserve accountable review?
These are evaluation questions, not a list of represented features.
API evaluation questions
How can we review the API?
Contact the team with the workflow and technical requirements you need to evaluate. The review focuses on available objects, access, validation, failure handling, and the expected record.
Can the API make a control pass automatically?
No. Evidence and status exchange should not replace the review needed to reach a control conclusion. See the evidence review boundary.
Can we email credentials or evidence samples?
No. Use the initial email to describe the workflow without sensitive material. A secure evaluation process must be agreed separately.
Define the handoff
Bring one system event you want to turn into a reviewable record.
We will map the source, payload, ownership, failure path, and expected outcome before discussing implementation.
Prepare an API workflow review