title: From a first check to a reliable data feed description: The complete PyCharter experience: describe, verify, deliver, inspect, repeat and recover through the interface you prefer.
From a first check to a reliable data feed¶
Describe what acceptable data means. Verify it. Deliver it. Keep it healthy.
That is the complete experience PyCharter is being built to provide. It connects small local checks to operated data feeds through the same reviewable requirements. You can stop at any useful level: validating a record is valuable on its own.
This page describes the intended end state, including interface behavior still being completed. Use capability status for availability and the first-result guide for runnable instructions today.
Start with the job¶
Choose Check my data or Create a reliable data feed. Bring a file, records, an existing contract or a source you want to connect. A credential-free example gives you a result before you configure infrastructure.
A returning user opens their existing work and sees what needs attention. The interface keeps the source, selected contract, parameters and prior results in context, so switching tasks or reopening a session does not restart setup.
Review the requirements¶
PyCharter proposes a draft from your sample or loads a contract you already own. You see the fields, conversions, required values and checks in a readable form, with the exact artifact available alongside it.
Observed sample properties, inferred rules and confirmed business requirements are distinguished. You decide material questions such as natural keys, missing values, precision and what to do with a rejected record. A small local task asks fewer questions than a recurring production feed.
Verify before delivery¶
A bounded verification shows the exact contract and transformation behavior, accepted records, rejected records and relevant limitations. The interface states whether a check is offline, reads a source, or writes a destination.
You can inspect a failure beside the affected field, correct the data or propose a reviewed contract change, then repeat the check. Verification never silently weakens a requirement to obtain a passing result.
Run and understand the result¶
Choose the destination and publication policy when you are ready to deliver. Review the source, destination, limits and intended effects once, then execute the verified definition within that authority.
The result answers four separate questions:
| Question | What you need to see |
|---|---|
| Execution | Completed, failed, interrupted or still running, with the relevant attempt |
| Acceptance | Acquired, accepted, rejected and unresolved data against the expected coverage |
| Publication | Committed, withheld, partial or unknown, under the selected destination policy |
| Health | Whether the latest accepted delivery meets current freshness and coverage requirements |
For a complete-publication feed expecting 20 records, one invalid record means 19 accepted, one rejected and zero published. The last accepted delivery stays visible with its own freshness. A completed process does not turn incomplete data into a successful delivery.
Keep the work and use your preferred interface¶
Export the exact reviewed contract, pipeline, permitted configuration and sample fixture. The Python example or terminal command continues that same work. Secrets remain references rather than being copied into artifacts or prompts.
An agent can inspect the same requirements and results, propose a bounded change, run the same checks and explain its evidence. A human can take over without reconstructing the task from chat history. Switching between UI, Python, CLI, HTTP and MCP preserves identity and meaning; each interface exposes the capabilities appropriate to its operating profile.
Keep the data updated¶
When you select Keep this updated, choose the required cadence, freshness, limits and alert destination. Existing connections and confirmed choices carry forward. Scheduling introduces the necessary runtime and durable state at this point; it is not a prerequisite for local validation.
Review the generated deployment and verify a bounded first delivery. The dataset view then shows last accepted publication, expected coverage, next delivery due, monitor status and any action required. Independent monitoring detects a missed delivery even when ingestion is stopped.
Recover and change with confidence¶
An interruption leaves enough evidence for a fresh process, person or agent to identify committed work, unfinished partitions and unknown external effects. The next action is specific: retry a safe request, resume remaining work, reconcile an uncertain commit or review a changed requirement.
A proposed change shows the relevant difference and verification result before promotion. Governed deployments require approval from an authorized distinct principal. Configuration rollback and reversal of already committed data are separate operations.
Grow only as far as you need¶
| Starting point | What you adopt | What you add later |
|---|---|---|
| Application validation | Python and a contract | Shared registry or additional enforcement points |
| Local batch | Files, a pipeline and explicit contracts | Database destination, durable evidence and scheduling |
| Streaming | A supported broker, worker and delivery policy | Operational monitoring and tested replay procedures |
| Shared team or agent service | Authenticated interfaces and permitted resources | Governance, lifecycle policy and qualified service operation |
The bounded FMP reference exercises part of this operational path today in a reviewed checkout. Broader source coverage, seamless interface handoff and the complete scheduled journey are being qualified.